ETSITS100 942V7.1.0 



(2000-09) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 
Point-to-Point (PP) Short Message Service (SMS) 

Support on Mobile Radio Interface 
(3GPP TS 04.11 version 7.1.0 Release 1998) 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 



3m^ 





3GPP TS 04.1 1 version 7.1 .0 Release 1 998 1 ETSI TS 1 00 942 V7.1 .0 (2000-09) 



Reference 



RTS/TSGN-010411V710 
Keywords 



GSM 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(5)etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2000. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 2 ETSI TS 1 00 942 V7.1 .0 (2000-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/kev . 



ETSI 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 3 ETSI TS 1 00 942 V7.1 .0 (2000-09) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 7 

1 Scope 8 

1.1 References 8 

1.2 Abbreviations 8 

2 Overview of Short Message Service (SMS) support 8 

2.1 Protocols and protocol architecture 9 

2.2 Use of channels 10 

2.3 Layer 2 SAPI 3 handling for circuit switched GSM 10 

2.4 Layer 2 (LLC) GPRS support 10 

3 Service definition 11 

3.1 General 11 

3.2 Service provided by the CM-sublayer 11 

3.2.1 Definition of primitives on the MS side 12 

3.2.1.1 MNSMS-ABORT-REQuest 12 

3.2.1.2 MNSMS-DATA-REQuest 12 

3.2.1.3 MNSMS-DATA-lNDication 12 

3.2.1.4 MNSMS-ESTablish-REQuest 13 

3.2.1.5 MNSMS-ESTablish-lNDication 13 

3.2.1.6 MNSMS-ERROR-lNDication 13 

3.2.1.7 MNSMS-RELease-REQuest 13 

3.2.2 Definition of primitives on the network side 13 

3.2.2.1 MNSMS-ABORT-REQuest 13 

3.2.2.2 MNSMS-DATA-REQuest 14 

3.2.2.3 MNSMS-DATA-lNDication 14 

3.2.2.4 MNSMS-ESTablish-REQuest 14 

3.2.2.5 MNSMS-ESTablish-lNDication 14 

3.2.2.6 MNSMS-ERROR-lNDication 14 

3.2.2.7 MNSMS-RELease-REQuest 14 

3.3 Service provided by SM-RL 14 

3.3.1 Definition of primitives on the MS side 15 

3.3.1.1 SM-RL-DATA-REQuest 15 

3.3.1.2 SM-RL-DATA-lNDication 15 

3.3.1.3 SM-RL-MEMORY-AVAlLABLE-REQuest 15 

3.3.1.4 SM-RL-REPORT-REQest 15 

3.3.1.5 SM-RL-REPORT-lNDication 16 

3.3.2 Definition of primitives on the network side 16 

3.3.2.1 SM-RL-DATA-REQuest 16 

3.3.2.2 SM-RL-DATA-INDication 16 

3.3.2.3 SM-RL-MEMORY-AVAlLABLE-lNDication 16 

3.3.2.4 SM-RL-REPORT-REQuest 16 

3.3.2.5 SM-RL-REPORT-lNDication 16 

4 [Spare] 17 

5 CM-procedures 17 

5.1 General 17 

5.2 Short Message Control states 17 

5.2.1 SMC-CS states at the MS side of the radio interface 17 

5.2.1.1 Mobile Originating Case 17 

5.2.1.1.1 MO-ldle (State 0) 17 

5.2.1.1.2 MO-MM-connection pending (State 1) 17 

5.2.1.1.3 MO-Wait for CP-ACK (State 2) 17 

5.2.1.1.4 MO-MM-connection established (State 3) 17 



£75/ 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 4 ETSI TS 1 00 942 V7.1 .0 (2000-09) 

5.2.1.2 Mobile Terminating case 17 

5.2.1.2.1 MT-Idle (State 0) 18 

5.2.1.2.2 MT- Wait for CP-ACK (State 2) 18 

5.2.1.2.3 MT-MM-connection established (State 3) 18 

5.2.2 SMC-GP states at the MS side of the radio interface 18 

5.2.2.1 Mobile Originating Case 18 

5.2.2.1.1 MO-Idle (State 0) 18 

5.2.2.1.2 MO-Wait for CP-ACK (State 1) 18 

5.2.2.1.3 MO-Wait for CP-Data (State 2) 18 

5.2.2.2 Mobile Terminating case 18 

5.2.2.2.1 MT-Idle (State 0) 18 

5.2.2.2.2 MT- Wait for RP-ACK (State 1) 18 

5.2.2.2.3 MT- Wait for CP-ACK (State 2) 18 

5.2.3 SMC-CS states at the network side of the radio interface 19 

5.2.3.1 Mobile Originating Case 19 

5.2.3.1.1 MO-Idle (State 0) 19 

5.2.3.1.2 MO-Wait for CP-ACK (State 2) 19 

5.2.3.1.3 MO-MM-connection established (State 3) 19 

5.2.3.2 Mobile Terminating Case 19 

5.2.3.2.1 MT-Idle (State 0) 19 

5.2.3.2.2 MT-MM-connection pending (State 1) 19 

5.2.3.2.3 MT- Wait for CP-ACK (State 2) 19 

5.2.3.2.4 MT-MM-connection estabHshed (State 3) 19 

5.2.4 SMC-GP states at the network side of the radio interface 19 

5.2.4.1 Mobile Originating Case 19 

5.2.4.1.1 MO-Idle (State 0) 20 

5.2.4.1.2 MO-Wait for RP-ACK (State 1) 20 

5.2.4.1.3 MO-Wait for CP-ACK(State 2) 20 

5.2.4.2 Mobile Terminating Case 20 

5.2.4.2.1 MT-Idle (State 0) 20 

5.2.4.2.2 MT- Wait for CP-ACK (State 1) 20 

5.2.4.2.3 MT-Wait for CP DATA (State 2) 20 

5.3 Short Message Control procedures 20 

5.3.1 MM-connection establishment for circuit switched GSM 20 

5.3.2.1 RPDU transfer for circuit switched GSM 21 

5.3.2.2 RPDU transfer for GPRS 21 

5.3.3 Release of MM and CM connections 22 

5.3.4 Abnormal cases 22 

5.4 Concatenating short message or notification transfers 23 

6 SM-RL-procedures 23 

6.1 General 23 

6.2 Transition states of SMR entity 23 

6.2.1 SMR-states at the MS-side of the radio interface 23 

6.2.1.1 Idle (State 0) 24 

6.2.1.2 Wait for RP-ACK (State 1) 24 

6.2.1.3 Wait for RETRANS TIMER (State 4) 24 

6.2.2 SMR-states at the network side of the radio interface 24 

6.2.2.1 Idle (State 0) 24 

6.2.2.2 Wait for RP-ACK (State 1) 24 

6.2.2.3 Wait to send RP-ACK (State 3) 24 

6.3 Short Message Relay procedures 24 

6.3.1 TPDU relaying 24 

6.3.2 [spare] 25 

6.3.3 Notification relaying 25 

6.3.3.1 MS side 25 

6.3.3.1.1 Idle state 25 

6.3.3.1.2 Wait for RP-ACK state 25 

6.3.3.1.3 Wait for RETRANS Timer state 26 

6.3.3.2 Network side 26 

6.3.3.2.1 Idle state 26 

6.3.3.2.2 Wait to Send RP-ACK state 26 



£75/ 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 5 ETSI TS 1 00 942 V7.1 .0 (2000-09) 

6.3.4 Abnormal cases 26 

7 Message functional definitions and content 26 

7.1 General 26 

7.2 Messages for short message or notification transfer on CM 27 

7.2.1 CP-DATA 27 

7.2.2 CP-ACK 27 

7.2.3 CP-ERROR 27 

7.3 Messages for short message and notification transfer on SM-RL 28 

7.3.1 RP-DATA 28 

7.3.1.1 RP-DATA (Network to Mobile Station) 28 

7.3.1.2 RP-DATA (Mobile Station to Network) 28 

7.3.2 RP-SMMA 28 

7.3.3 RP-ACK 28 

7.3.4 RP-ERROR 29 

8 Message format and information elements coding 29 

8.1 CP-messages 29 

8.1.1 General 29 

8.1.2 Protocol Discriminator and Transaction Identifier 29 

8.1.3 Message type 30 

8.1.4 Other required information elements 30 

8.1.4.1 CP-User data element 30 

8.1.4.2 CP-Cause element 30 

8.2 RP-messages 31 

8.2.1 General 31 

8.2.2 Message type indicator (MTI) 31 

8.2.3 Message reference 32 

8.2.4 [Spare] 32 

8.2.5 Other required information elements 32 

8.2.5.1 Originator address element 32 

8.2.5.2 Destination address element 32 

8.2.5.3 RP-User data element 33 

8.2.5.4 RP-Cause element 33 

9 Handling of unknown, unforeseen, and erroneous protocol data 35 

9.1 General 35 

9.2 CP Error Handling 35 

9.2.1 Message too short 36 

9.2.2 Unknown or unforeseen transaction identifier 36 

9.2.3 Unknown or unforeseen message type 36 

9.2.4 Non-semantical mandatory information element errors 36 

9.2.5 Messages with semantically incorrect contents 37 

9.3 RP Error Handling 37 

9.3.1 Message too short 37 

9.3.2 Unknown or unforeseen Message Reference 37 

9.3.3 Unknown or unforeseen message type 37 

9.3.4 Non-semantical mandatory information element errors 38 

9.3.5 Messages with semantically incorrect contents 38 

10 Timers 38 

Annex A (informative) : Arrow diagrams 39 

Annex B (normative): SDL-description of the CM-layer 42 

B.l Introduction 42 

Annex C (informative) : Arrow diagrams 53 

Annex D (normative): SDL-description of the short message relay layer 59 

D.l Introduction 59 



£75/ 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 6 ETSI TS 1 00 942 V7.1 .0 (2000-09) 

Annex E (informative) : Cause definition 67 

Annex F (informative): LAPDm SAPI 3 handling for short message service 72 

Annex G (informative): Change history 79 

History 80 



£75/ 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 7 ETSI TS 1 00 942 V7.1 .0 (2000-09) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This Technical Specification (TS) specifies the procedures used across the mobile radio interface by the signalling layer 
3 function Short Message Control (SMC) and Short Message Relay function (SM-RL) for both circuit switched GSM 
and GPRS. 

1.1 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[1] 3GPP TS 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 



[2] 3GPP TS 03.40: "Digital cellular telecommunications system (Phase 2+) 

the Short Message Service (SMS) Point-to-Point (PP)". 

[3a] 3GPP TS 03.60: "Digital cellular telecommunications system (Phase 2+) 

Service (GPRS); Service description; Stage 2". 

[3] 3GPP TS 04.06: "Digital cellular telecommunications system (Phase 2+) 

Station System (MS - BSS) interface Data Link (DL) layer specification' 

[4] 3GPP TS 04.07: "Digital cellular telecommunications system (Phase 2+) 

signalling layer 3; General aspects". 

[5] 3GPP TS 04.08: "Digital cellular telecommunications system (Phase 2+) 

layer 3 specification". 

[6a] 3GPP TS 04.64: "Digital cellular telecommunications system (Phase 2+) 

Service (GPRS); Logical Link Control (LLC)". 



Technical realization of 



General Packet Radio 



Mobile Station - Base 



Mobile radio interface 



Mobile radio interface 



General Packet Radio 



[6] ISO 7498: "Information processing systems - Open Systems Interconnection - Basic Reference 

Model". 

1 .2 Abbreviations 

Abbreviations used in this TS are listed in 3GPP TS 01.04. 

2 Overview of Short IVIessage Service (SIVIS) support 

The purpose of the Short Message Service is to provide the means to transfer messages between a GSM PLMN Mobile 
Station (MS) and a Short Message Entity via a Service Centre, as described in 3GPP TS 03.40. The terms "MO" - 
Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the direction in which the short message is 
sent. 
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This ETS describes the procedures necessary to support the Short Message Service between the MS and the MSC or 
SGSN and vice versa, as described in 3GPP TS 03.40. 

The procedures are based on services provided by the MobiHty Management sublayer as described in 3GPP 

TS 04.07/04.08 for GSM services and the Logical Link Control layer described in GSM 04.64 for GPRS services 

2.1 Protocols and protocol architecture 

The hierarchical model in Figure 2.1a shows the layer structure of the MSC and the MS. 





MSC 










SM-AL 




SM-TL 




SM-RL 


SMR 


< 


CM-sublayer 


SMC 




^ 


MM-sublayer 
RR-sublayer 







MS 



SM-RP protocol > 

■ SM-CP protocol > 



SMR 



SMC 



Figure 2.1a/3GPP TS 04.1 1 : Protocol hierarchy for circuit switched service 

The hierarchical model in Figure 2.1b shows the layer structure of the SGSN and the MS. 



SGSN 



MS 



SM-AL 



SM-TL 



SM-RL 



SMR 



SMC 



■ SM-RP protocol - 
SM-CP protocol - 



SMR 



SMC 



CM-sublayer 

LLC-sublayer 

GRR-sublayer 

Figure 2.1b/3GPP TS 04.11: Protocol hierarchy for GPRS 

The CM-sublayer, in terms of the Short Message Service Support, provides services to the Short Message Relay Layer. 

On the MS-side the Short Message Relay Layer provides services to the Short Message Transfer Layer. The Short 
Message Relay Layer is the upper layer on the network side (MSC or SGSN), and the SM-user information elements 
are mapped to TCAP/MAP. 

The peer protocol between two SMC entities is denoted SM-CP, and between two SMR entities, SM-RP. 

Abbreviations: 

SM-AL Short Message Application Layer 

SM-TL Short Message Transfer Layer 

SM-RL Short Message Relay Layer 

SM-RP Short Message Relay Protocol 

SMR Short Message Relay (entity) 

CM-sub Connection Management sublayer 

SM-CP Short Message Control Protocol 

SMC Short Message Control (entity) 

MM-sub: Mobility Management sublayer 

RR-sub: Radio Resource Management sublayer 

LLC-sub Logical Link Control sublayer 

GRR-sub GPRS Radio Resource sublayer 
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2.2 



Use of channels 



Table 2.1/3GPP TS 04.11 summarizes the use of channels for the short message service for circuit switched GSM. 
Arrows indicate changes of channel. 

Table 2.1/3GPP TS 04.1 1 : Channels used for short message transfer over circuit switched GSM 



Channel dependency 


Channel used 


TCH not allocated 

TCH not allocated -> TCH allocated 

TCH allocated 

TCH allocated -> TCH not allocated 


SDCCH 

SDCCH -> SACCH 

SACCH 

SACCH -> SACCH opt. SDCCH^ 



The short message service for GPRS shall be supported by a PDTCH. 

2.3 Layer 2 SAPI 3 handling for circuit switched GSIVI 

General rule: 

The Radio Resource Management (RR reference 3GPP TS 04.08) in the Mobile Station and on the network side (i.e. in 
the BSC) shall establish the acknowledged mode of operation on SAPI 3 whenever needed, i.e. when a message 
requiring SAPI 3 transfer shall be transmitted. 

RR shall control the layer 2 also for SAPI 3, and keep knowledge of the mode. 

The network side may initiate release of the acknowledged mode for SAPI 3 either explicitly (by the use of DISC- and 
UA-frames, see 3GPP TS 04.06) or indirectly by channel release (see 3GPP TS 04.08). 

This means: 

the Mobile Station side will initiate establishment of SAPI 3 acknowledged mode in the case of mobile 
originating short message transfer; 

the network side will initiate establishment of SAPI 3 acknowledged mode in the case of mobile terminating 
short message transfer; 

the network side may choose to keep the channel and the acknowledged mode of operation to facilitate transfer 
of several short messages for or from the same Mobile Station. The queuing and scheduling function for this 
should reside in the MSC. 



2.4 Layer 2 (LLC) GPRS support 



It shall be possible for a GPRS-attached MS of any class (A, B, C) to send and receive short messages over GPRS radio 
channels. 

GPRS shall use the unacknowledged mode of LLC frame transfer as described in GSM 04.64, and shall use SAPI 7 to 
identify the SMS Logical Link Entity within the LLC layer. 

A description of the different GPRS MS classes can be found in 03.60, and a brief overview is given below:- 

Class A/B MSs may be able to send and receive short messages using either the MM sublayer (using SACCH or 
SDCCH) or the LLC layer (using PDTCH). 

Class C MSs may be able to send and receive short messages using only the LLC layer (using the PDTCH). The 
capability for GPRS-attached class-C MSs to receive and transmit SMS messages is optional. 

The GSMS entity for GPRS class A/B MS is shown in Figure 3. The GSMS shall communicate with the MM entity via 
the GMMSMS-SAP for GPRS Class A/B MO SMS, in order to ascertain which transport service to use. 

SMS delivery via GPRS is normally a more radio resource efficient method than SMS delivery via CS GSM. The 
deUvery path for MO SMS is selected by the MS. 
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MNSMSSAP 



SMSMM 



SMC-GP 



LLSMSSAP 



SMC-CS 



MMSMS 



SAP 



GMMSMS-SAP 
Figure 3/3GPP TS 04.11 : GSMS entity for GPRS Class A/B IVIS 



3.1 



Service definition 



General 



The layer service is described as a set of service primitives. These service primitives are abstractions and attempt to 
capture only those details of the interaction between the entities that are aspects of the layer service itself. A service 
primitive neither specifies nor constrains the implementation of entities or the interface between them. 

The general syntax of a primitive and the initials of them are in line with the 04-series of GSM Technical 
Specifications. 

NOTE: In order to limit the number of primitives and state definitions to a reasonable amount, a description 

method has been chosen which does not claim to be totally in line with the formal description method of 
the layered ISO reference model (ISO 7498) for Open Systems Interconnection. 

3.2 Service provided by the CIVI-sublayer 

In order to support the Short Message Service, the CM-sublayer provides services to the Short Message Relay Layer. 

The CM-sublayer services are provided using layer specific functions and lower layer services offered to the 
CM-sublayer, controlled by short message service control entities called SMCs. 

An SMC entity in the MS communicates with an SMC entity in the MSC or SGSN by means of a peer protocol, SM-CP 
(Short Message Service Control Protocol). The arrow diagrams in annex A give an overview of the messaging on the 
CM-sublayer during a short message transfer. 

A mobile station supporting the Short Message Service shall have a minimum of two SMC entities per service type (i.e. 
two for CS GSM and two for GPRS). This enables the MS to receive MT messages during an MO message transfer. 

To ensure that an MS having the minimum of two SMC entities is able to receive MT messages during an MO message 
transfer, and to send MO messages during MT message transfer, parallel message transfer in the same direction is 
prohibited. This means that the SMC entities shall not simultaneously perform messaging in the same direction. The 
rules for concatenation of message transfers are described in subclause 5.4. 

The MSC or SGSN shall have a minimum of two SMC entities available each during an MT message transfer to a 
mobile station, one being reserved for MO message transfer. In an MO message transfer, the MSC or SGSN shall have 
one SMC entity reserved for handling of an MT message. 
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3.2.1 Definition of primitives on tine MS side 

This subclause defines the service primitives used on the MS side. Table 3.1/3GPP TS 04.11 gives an overview of the 
service primitives and main parameter linked to the primitives. All necessary control parameters to be used in the Short 
Message Service are defined in clause 7. All MNSMS service primitives defined in this subclause are passed to an 
SMC-entity. 

Table 3.1/3GPP TS 04.1 1 : MNSMS service primitives on the MS-side 



SERVICE PRIMITIVES 


PARAMETER 


NAME 


TYPE 


MNSMS-ABORT- 


Req 


Cause 


MNSMS-DATA 


Req 


MTRPDU 


Ind 


MO RPDU 


MNSMS-EST- 


Req 


MO RPDU 


Ind 


MT RPDU 


MNSMS-ERROR- 


Ind 


Cause 


MNSMS-REL- 


Req 


Cause 



3.2.1.1 MNSMS-ABORT-REQuest 

A request from an SMR entity to release a CM-connection in abnormal cases. 

When the CM-sublayer receives this request, and if the MM connection exists, it shall form and send the CP-ERROR 
message. Irrespective of whether or not the CP-ERROR message was sent, the CM-sublayer shall then release the lower 
layer services. 

3.2.1.2 MNSMS-DATA-REQuest 

A request from an SMR entity to send a RPDU on the established CM-connection. 

The SMC entity forms the CP-DATA message, the user information element being the RPDU, and transfers the 
message by means of the lower layer services. 

NOTE: After reception of an incoming RP-DATA, the SMR entity typically returns the acknowledgement 
RP-ACK, or an error indication, RP -ERROR, to the Service Centre. 



3.2.1.3 



MNSMS-DATA-INDication 



An indication used by the SMC entity to pass the user information element (RPDU) of a received CP-DATA message to 
SM-RL. 

NOTE: The RPDU is typically an RP-ACK or an RP -ERROR. Normally this service is used to report the 

outcome of either a MO message transfer attempt or a mobile station memory available notification 
attempt. 
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3.2.1.4 



MNSMS-ESTablish-REQuest 



A request from an SMR entity to establish a CM-connection. The request contains a RP-DATA UNIT as a parameter. It 
implies the: 

establishment of a CM-connection for this SMR entity; 

forming of the CP-DATA message containing the RPDU; and 

- passing of CP-DATA to the MM-sublayer. 



3.2.1.5 



MNSMS-ESTablish-INDication 



An indication used by the SMC entity to pass the SM-user information (RPDU) of a received CP-DATA message to 
SM-RL. It implies completion of the establishment of the CM-connection for this SMR entity. 



3.2.1.6 



MNSMS-ERROR-INDication 



An indication used by the SMC entity to pass error information to SM-RL. The error information may be local or 
relayed by the CP-ERROR message. 

Use of this service primitive implies release of both CM and MM-connection. 

3.2.1.7 MNSMS-RELease-REQuest 

A request to release the CM-connection (if it still exists). 

Use of this service primitive implies release of the associated CM and MM-connections. 

3.2.2 Definition of primitives on tine network side 

This subclause defines the service primitives used on the network side. 

Table 3.2/3GPP TS 04. 1 1 gives an overview of the service primitives and linked main parameter. All MNSMS service 
primitives defined in this subclause are passed to an SMC-entity. 

Table 3.2/3GPP TS 04.1 1 : MNSMS service primitives on thie networl< side 



SERVICE PRIMITIVES 


PARAMETER 


NAME 


TYPE 


MNSMS-ABORT- 


Req 


Cause 


MNSMS-DATA 


Req 


MO RPDU 


Ind 


MT RPDU 


MNSMS-EST- 


Req 


MT RPDU 


Ind 


MO RPDU 


MNSMS-ERROR- 


Ind 


Cause 


MNSMS-REL- 


Req 


Cause 



3.2.2.1 MNSMS-ABORT-REQuest 

A request from an SMR entity to release a CM-connection in abnormal cases. 

When the CM-sublayer receives this request, it may form and send the CP-ERROR message to release the connection. 
Irrespective of whether or not the CP-ERROR message was sent, the CM-sublayer shall then release the lower layer 

services. 
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3.2.2.2 MNSMS-DATA-REQuest 

A request from an SMR entity to send a RPDU on the established CM -connection. 

The SMC entity forms the CP-DATA message, the user information element being the RPDU, and transfers the 
message by means of the lower layer services. 

NOTE: After reception of an incoming RP-DATA or RP-SMMA the RPDU typically returns the 
acknowledgement, RP-ACK, or an error indication RP -ERROR, to the Mobile Station. 

3.2.2.3 MNSMS-DATA-INDication 

An indication used by the SMC entity to pass the user information element (RPDU) of a received CP-DATA message to 
SM-RL. 

NOTE: The RPDU is typically an RP-ACK or an RP-ERROR. Normally this is used to report the outcome of a 
MT messaging attempt. 

3.2.2.4 MNSMS-ESTablish-REQuest 

A request from an SMR entity to transmit a RPDU, containing the SM-user information element; it implies the: 
establishment of a CM-connection for this SMR entity; 
forming of the CP-DATA message containing the RPDU; and 
- passing of CP-DATA to the MM-sublayer. 

3.2.2.5 MNSMS-ESTablish-INDication 

An indication used by the SMC entity to pass the SM-user information (RPDU) of a received CP-DATA message to 
SM-RL; it implies completion of the establishment of the CM-connection for this SMR entity. 

3.2.2.6 MNSMS-ERROR-INDication 

An indication used by the SMC entity to pass error information to SM-RL. The error information may be local or 
relayed by the CP-ERROR message. 

Use of the service primitive implies release of both CM and MM-connection. 

3.2.2.7 MNSMS-RELease-REQuest 

A request to release the CM-connection (if it still exists). 

Use of this service implies release of the associated CM and MM-connections. 



3.3 Service provided by SIVI-RL 



In order to support the Short Message Service, the Short Message Relay Layer provides services to the Short Message 
Transfer Layer. 

The Short Message Relay Layer services are provided using layer specific functions and lower layer services offered to 
the Short Message Relay Layer, controlled by short message control entities called SMRs. 

An SMR entity in the MS communicates with an SMR entity in the MSC by means of a peer protocol, SM-RP (Short 
Message Relay Protocol). The arrow diagrams in annex C give an overview of the messaging on the Short Message 
Relay Layer used for the Short Message Service. The diagrams in annex C indicate a layer RL. This is not a layer, but 
the functional interface to the fixed network. The SM-RL is the upper layer in the MSC. Consequently the service 
primitives passed between SM-RL and RL indicate the interworking function. 

The requirements on the SM-RL are the same as for the CM-sublayer. This means that there is exactly one SMR entity 
for each SMC entity, operating as described in subclause 3.2. 
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3.3.1 Definition of primitives on tine MS side 

This subclause defines the service primitives used on the MS side. Table 3.3/3GPP TS 04.11 gives an overview of the 
service primitives and linked main parameters. All SM-RL service primitives defined in this subclause are passed on an 
SM-RL-connection. 

Table 3.3/3GPP TS 04.11 : SM-RL service primitives on thie mobile station side 



SERVICE PRIMITIVES 


PARAMETER 


NAME 


TYPE 


SM-RL-DATA- 


Req 


MO SMS-TPDU 


Ind 


MT SMS-TPDU 


SM-RL-MEMORY 
AVAILABLE 


Req 


See subclause 3.3.1.3 


SM-RL-REPORT- 


Req 


See subclause 3.3.1.4 


Ind 


See subclause 3.3.1.5 



3.3.1.1 SM-RL-DATA-REQuest 

A request from the SM-TL entity to pass the SMS-TPDU and necessary control information to SM-RL; it implies: 
establishment of an SM-RL connection for MO message transfer; 

- forming of the RP-DATA message, containing the SMS-TPDU; 

- transfer of the RP-DATA message as an RPDU in an MNSMS-EST-Req. 

The purpose of this service is to relay the SMS-TPDU from the mobile station to the peer entity in the MSC. 



3.3.1.2 



SM-RL-DATA-INDication 



An indication used by the SMR entity to pass the SMS-TPDU and necessary control information of a received 
RP-DATA message to SM-TL. 



3.3.1.3 



SM-RL-MEMORY-AVAILABLE-REQuest 



When received without a parameter, this is a request from the SM-TL entity to pass the necessary control information to 
SM-RL; it imphes: 

establishment of an SM-RL-connection for transfer of the notification to the network that the mobile has 
memory available to receive one or more short messages; 

- forming the RP-SM-MEMORY-AVAILABLE message; and 

- transfer of the RP-SM-MEMORY-AVAILABLE message as an RPDU in an MNSMS-EST-Req. 

The SM-TL entity may abort the transmission of an RP-SM-MEMORY-AVAILABLE message by use of a 
SM-RL-MEMORY-AVAILABLE-REQuest with the added parameter, SMS-MEM-NOTIF-ABORT, being present. 
This parameter is, of course, defined only on the interface between the SM-TL and SMR entities within the mobile 
station. Use of this request with the added parameter will have no effect on messages already given to the lower layers 
for transmission, but will only abort retransmission of the RP-SM-MEMORY-AVAILABLE message by the SMR 
entity. 



3.3.1.4 



SM-RL-REPORT-REQest 



A request used by the SM-TL to relay the RP-ACK or RP-ERROR message from the mobile station to the network. 
This implies transfer of the RP-ACK or RP-ERROR message as an RPDU in an MNSMS-DATA-Req. 
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3.3.1.5 



SM-RL-REPORT-INDication 



An indication used by the SMR entity to pass an acknowledgement (RP-ACK) or error information to SM-TL. The 
error information may be local or relayed by the RP-ERROR message; it consists of an appropriate cause and optionally 
extended diagnostic information. 

3.3.2 Definition of primitives on tine networl< side 

This subclause defines the service primitives used on the network side. 

Table 3.4/3GPP TS 04. 1 1 gives an overview of the service primitives and linked main parameter. All SM-RL service 
primitives defined in this subclause are passed on an SM-RL-connection. 

Table 3.4/3GPP TS 04.11 : SM-RL service primitives on the networit side 



SERVICE PRIMITIVES 


PARAMETER 


NAME 


TYPE 


SM-RL-DATA- 


Req 


MTSMS-TPDU 


Ind 


MO SMS-TPDU 


SM-RL-MEMORY 
AVAILABLE 


Ind 


None 


SM-RL-REPORT- 


Req 


See subclause 3.3.2.4 


Ind 


See subclause 3.3.2.5 



3.3.2.1 SM-RL-DATA-REQuest 

A request from RL to pass the SMS-TPDU to SM-RL; it impHes: 

establishment of a SM-RL-connection for MT message transfer; 

forming of the RP-DATA message, containing the SMS-TPDU; and 
- transfer of the RP-DATA message as an RPDU in an MNSMS-EST-Req. 
The purpose of this service is to relay the SMS-TPDU from the MSC to the peer entity in the mobile station. 

3.3.2.2 SM-RL-DATA-INDication 

An indication used by the SMR entity to pass the SMS-TPDU of a received RP-DATA message to RL. 

3.3.2.3 SM-RL-MEMORY-AVAILABLE-INDication 

An indication used by the SMR entity to pass to RL the notification to the network that the mobile has memory 
available to receive one or more short messages. 



3.3.2.4 



SM-RL-REPORT-REQuest 



A request used by RL (the network interworking function) to relay the RP-ACK or RP-ERROR message from the 
network to the mobile station. This implies transfer of the RP-ACK or RP-ERROR message as an RPDU in an 
MNSMS-DATA-Req. 



3.3.2.5 



SM-RL-REPORT-INDicatlon 



An indication used by the SMR entity to pass an acknowledgement (RP-ACK) or error information to RL. The error 
information may be local or relayed by the RP-ERROR message. 
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[Spare] 
CM-procedures 



5.1 General 

This clause describes the procedures used by the SMC entity on the Connection Management sublayer. An SMC entity 
communicates with a corresponding peer entity using an MM-connection for CS GSM or the LLC layer for GPRS. 

Multiple MM-connections may be established at the same time, allowing parallel transactions. The description of the 
procedures is related to one single transaction. 

For circuit switched GSM, the CM-procedures described can only be performed if an MM-connection has been 
established between the mobile station and the network. For GPRS, no MM-connection has to be established, and thus 
the CM procedures for GPRS reflect this. Detailed SDL diagrams for SMC entities are contained in annex B. 

5.2 Short Message Control states 

The state transition diagrams for the MO and MT SMC entities on both the MS side and network side are contained in 
annex B. 

5.2.1 SMC-CS states at the MS side of the radio interface 

5.2.1 .1 Mobile Originating Case 

The states described in this clause are for an SMC entity in an MS handling mobile originating short message transfer 
and notification to the network that the mobile has memory available to receive one or more short messages (referred to 
below as "notification"). 

5.2.1.1.1 MO- Idle (State 0) 

This state exists when the MO-SMC entity is in idle mode, or when an MO short message transfer or notification ends 
in a normal or abnormal way. 

5.2.1.1.2 MO-MM-connectlon pending (State 1 ) 

This state exists when the MO-SMC has requested the establishment of an MM-connection. 

5.2.1.1.3 MO-Wait for CP-ACK (State 2) 

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message. 

5.2.1.1.4 MO-MM-connection established (State 3) 

This state exists when the MO-SMC has: 

received the acknowledgement, CP-ACK; or 

received the message CP-DATA (including sending of the associated CP-ACK). 

5.2.1 .2 Mobile Terminating case 

The states described in this subclause are for an SMC entity in an MS handling mobile terminating short message 
transfer. 
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5.2.1.2.1 MT-ldle (State 0) 

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or 
abnormal way. 

5.2.1 .2.2 MT-Wait for CP-ACK (State 2) 

This state exists after the MT-SMC has initiated the transfer of a CP-DATA message. 

5.2.1 .2.3 MT-MM-connection established (State 3) 

This state exists when the MT-SMC has: 

received the acknowledgement, CP-ACK; or 

received the message CP-DATA (including sending of the associated CP-ACK). 

5.2.2 SMC-GP states at the MS side of the radio interface 

5.2.2.1 Mobile Originating Case 

The states described in this clause are for an SMC-GP entity in a GPRS MS handling mobile originating short message 
transfer and notification to the network that the mobile has memory available to receive one or more short messages 
(referred to below as "notification"). 

5.2.2.1.1 MO- Idle (State 0) 

This state exists when the MO-SMC entity is in idle mode, or when an MO short message transfer or notification ends 
in a normal or abnormal way. 

5.2.2.1.2 MO-Wait for CP-ACK (State 1 ) 

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message. 

5.2.2.1 .3 MO-Wait for CP-Data (State 2) 

This state exists when the MO-SMC has received the acknowledgement, CP-ACK. 

5.2.2.2 Mobile Terminating case 

The states described in this subclause are for an SMC-GP entity in an GPRS MS handling mobile terminating short 
message transfer. 

5.2.2.2.1 MT-ldle (State 0) 

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or 
abnormal way. 

5.2.2.2.2 MT-Wait for RP-ACK (State 1 ) 

This state exists after the MT-SMC has received the message CP-DATA (including sending of the associated CP-ACK) 

5.2.2.2.3 MT-Wait for CP-ACK (State 2) 

This state exists when the MT-SMC has initiated the transfer of the CP DATA message. 
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5.2.3 SMC-CS states at the network side of the radio interface 

5.2.3.1 Mobile Originating Case 

The states described in this subclause are for an SMC entity in an MSC handling both mobile originating short message 
transfer and notification to the network that the mobile has memory available to receive one or more short messages 
(referred to below as "notification"). 

5.2.3.1.1 MO- Idle (State 0) 

This state exists when the MO-SMC entity is in idle mode, or when a short message transfer or notification ends in a 
normal or abnormal way. 

5.2.3.1.2 MO-Wait for CP-ACK (State 2) 

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message. 

5.2.3.1 .3 MO-MM-connection established (State 3) 

This state exists when the SMC has: 

received the acknowledgement, CP-ACK; or 

received the message CP-DATA (including sending of the associated CP-ACK). 

5.2.3.2 Mobile Terminating Case 

The states described in this subclause are for an SMC entity in an MSC handling mobile terminating short message 
transfer. 

5.2.3.2.1 MT-ldle (State 0) 

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or 
abnormal way. 

5.2.3.2.2 MT-MM-connection pending (State 1) 

This state exists when the MT-SMC has requested an MM -connection for mobile terminating short message transfer. 

5.2.3.2.3 MT-Wait for CP-ACK (State 2) 

This state exists after the SMC has initiated the transfer of a CP-DATA message. 

5.2.3.2.4 MT-MM-connection established (State 3) 

This state exists when the SMC has: 

received the acknowledgement, CP-ACK; or 

received the message CP-DATA (including sending of the associated CP-ACK). 

5.2.4 SMC-GP states at the network side of the radio interface 
5.2.4.1 Mobile Originating Case 

The states described in this subclause are for an SMC-GP entity in an SGSN handling both mobile originating short 
message transfer and notification to the network that the mobile has memory available to receive one or more short 
messages (referred to below as "notification"). 
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5.2.4.1.1 MO-ldle (State 0) 

This state exists when the MO-SMC entity is in idle mode, or when a short message transfer or notification ends in a 
normal or abnormal way. 

5.2.4. 1 .2 MO-Wait for RP-ACK (State 1 ) 

This state exists after the MO-SMC has received the message CP-DATA (including sending of the associated 
CP-ACK). 

5.2.4.1.3 MO-Wait for CP-ACK(State 2) 

This state exists when the SMC has received the RP acknowledgement, RP-ACK 

5.2.4.2 Mobile Terminating Case 

The states described in this subclause are for an SMC-GP entity in an SGSN handhng mobile terminating short message 
transfer. 

5.2.4.2.1 MT-ldle (State 0) 

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or 
abnormal way. 

5.2.4.2.2 MT-Wait for CP-ACK (State 1 ) 

This state exists after the SMC has initiated the transfer of a CP-DATA message. 

5.2.4.2.3 MT-Wait for CP DATA (State 2) 

This state exists when the SMC has received the acknowledgement, CP-ACK. 

5.3 Short Message Control procedures 

The procedures needed for short message control are: 

connection establishment procedures; 

- RP Data Unit (RPDU) transfer procedures; 

connection release procedures; and 

procedures for abnormal cases. 

The procedures of subclause 5.3 are described with respect to one particular instance of an SMC entity. Different SMC 
entities are identified by their Transaction Identifier. Messages with Transaction Identifiers that do not correspond to 
this particular instance of the SMC entity are not treated by it. 

5.3.1 MM-connection establishment for circuit switched GSM 

When an SMC entity is in the Idle state and transfer of an RPDU is requested, the peer to peer connection between the 
MM-sublayers in the MS and the network (MSC) has to be established. 

The SMC entity on the originating side requests the MM-sublayer to establish an MM-connection, and enters the 
MM-Connection Pending state. 

After completion of the MM-connection establishment, a confirmation is given to the originating side to indicate that 
the MM sublayer is ready for RPDU transfer. 



£75/ 



3GPP TS 04.1 1 version 7.1 .0 Release 1 998 21 ETSI TS 1 00 942 V7.1 .0 (2000-09) 

The MM-connection establishment is indicated to the SMC entity at the destination side when the CP-DATA message 
has been received by the MM-sublayer (in line with 3GPP TS 04.08). The destination side SMC entity then sends a 
CP-ACK and enters the MM-Connection Established state. 

5.3.2.1 RPDU transfer for circuit switched GSM 

When an SMC entity in the MM-Connection Pending state is informed that an MM-connection has been established, 
the SMC entity forwards the CP-DATA message containing the RPDU, sets the timer TCI* and enters the Wait for 
CP-ACK state. 

The value of TCI * may vary with the length of the CP-DATA message and the channel type that is being used for its 
transmission. However, the value of TCI* shall be sufficiently great to allow the lower layers to transmit the CP-DATA 
and CP-ACK messages and to allow for some retransmissions of layer 2 frames. 

If an SMC entity in the Wait for CP-ACK state gets an indication that the CP-DATA message has probably been lost 
(e.g. due to dedicated channel assignment, hand over, assignment failure, hand over failure, or a SAPI 3 data link 
failure) then, as an implementation option, that SMC entity may reduce the time until expiry of TCI*. 

If the timer TCI* expires in the Wait for CP-ACK state, the CP-DATA message is retransmitted and the state Wait for 
CP-ACK is re-entered. The maximum number of CP-DATA message retransmissions is an implementation option but 
shall be either 1, 2 or 3. If the timer TCI* expires after the maximum number of retransmission attempts, an error 
indication is passed to SM-RL and an MM-connection release request is passed to the MM-sublayer. The Idle state is 
then entered. 

On receipt of the CP-ACK message in the Wait for CP-ACK state, the SMC resets the timer TC 1 * and enters the 
MM-Connection Established state. 

When receiving a CP-DATA message in the MM-Connection Established state, the SMC entity checks the parameters 
relevant to the CP protocol. If these are valid, the RPDU is passed to the SM-RL, the CP-ACK message is sent and the 
state MM-Connection Established is re-entered. 

If an SMC entity in the Idle state is unable to accept a CP-DATA message, it sends a CP-ERROR message followed by 
an MM-connection release request and then enters the Idle state. 

When receiving a MNSMS-DATA-Req primitive in the MM-Connection Established state, the SMC entity forwards a 
CP-DATA message containing the RPDU to the MM-sublayer, sets the timer TCI* and enters the Wait for CP-ACK 

state. 

5.3.2.2 RPDU transfer for GPRS 

When an SMC-GP entity is in the Idle state and transfer of an RPDU is requested, the SMC-GP entity on the originating 
side forwards the CP-DATA message to the LLC sublayer. This contains the RPDU, and also the SMC-GP entity sets 
the timer TCI* and enters the Wait for CP-ACK state. 

The value of TCI* may vary with the length of the CP-DATA. However, the value of TCI* shall be sufficiently great 
to allow the lower layers to transmit the CP-DATA and CP-ACK messages and to allow for some re-transmissions of 
layer 2 frames. 

If an SMC entity in the Wait for CP-ACK state gets an indication that the CP-DATA message has probably been lost 
then, as an implementation option, that SMC-GP entity may reduce the time until expiry of TCI*. 

If the timer TCI* expires in the Wait for CP-ACK state, the CP-DATA message is retransmitted and the state Wait for 
CP-ACK is re-entered. The maximum number of CP-DATA message re-transmissions is an implementation option but 
shall be either 1, 2 or 3. If the timer TCI* expires after the maximum number of retransmission attempts, an error 
indication is passed to SM-RL. The Idle state is then entered. 

On receipt of the CP-ACK message in response to the CP-DATA (RP DATA) message in the Wait for CP-ACK state, 
the SMC-GP resets the timer TCI* and enters the Wait for CP DATA state. 

On receipt of the CP-ACK message in response to the CP-DATA (RP ACK) message in the Wait for CP-ACK state, the 
SMC-GP resets the timer TCI* and enters the Idle State. 

When receiving a CP-DATA message form the LLC sublayer, the SMC-GP entity checks the parameters relevant to the 
CP protocol. If these are valid, the RPDU is passed to the SM-RL, the CP-ACK message is sent. 
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If an SMC entity in the Idle state is unable to accept a CP-DATA message, it sends a CP-ERROR message and then 
enters the Idle state. 

5.3.3 Release of MM and CM connections 

With the exception of error situations, release of the MM and CM connection is controlled by the SM-RL. 

When an SMC entity in the Wait for CP-ACK state receives a release request from SM-RL, this request is stored until 
the next state (either MM Connection Established or Idle) is entered. If the Idle state is entered, the request is discarded. 
If the MM Connection Established state is entered, or if the SMC entity receives a release request from SM-RL in this 
state, an MM-connection release request is sent to the MM-sublayer and the SMC entity enters the Idle state. 

5.3.4 Abnormal cases 

Abnormal cases that shall be handled by the SMC entity in any state can be classified into five cases: 

Upper Layer Abort: Errors occurring in the SM-RL may cause the SM-RL to send an MNSMS-ABORT Request 
to the SMC entity. 

CP-Layer Abort: Errors occurring within the SMC entity itself may require termination of all activities related to 
that transaction identifier. 

Lower Layer Abort: Errors occurring within the layers beneath the CP -layer may cause an MMSM-ERROR 
Indication or a GMMSMS -ERROR Indication to be sent to the SMC entity. 

CP-Layer Protocol Errors: Errors occurring within the protocol exchange between the SMC entities may result in 
the sending of a CP-ERROR message between the entities. 

Lower Layer Release: Events occurring within the layers beneath the CP layer may cause an MMSM-REL 
Indication to be sent to the SMC entity. 

When the CM-sublayer in the network receives an Upper Layer Abort, it may form and send the CP-ERROR message 
to release the connection. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection release 
request, without indication of release cause, is passed to the MM-sublayer. The SMC entity in the network then enters 
the Idle state. 

When the CM-sublayer in the MS receives an Upper Layer Abort and if the MM connection exists, it shall form and 
send the CP-ERROR message. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection 
release request, without indication of release cause, is passed to the MM-sublayer. The SMC entity in the mobile station 
then enters the Idle state. 

In the case of a CP-Layer Abort, an error indication is passed to SM-RL. If possible, a CP-ERROR message is sent to 
the partner SMC entity to indicate the error situation. Then the SMC entity enters the Idle state. 

In the case of a Lower Layer Abort, the SMC entity passes an error indication to SM_RL, an MM-connection release 
request is passed to the MM-sublayer, and the SMC entity immediately enters the Idle state. 

In the case of the reception of a CP-ERROR message from the partner SMC entity, an error indication is passed to 
SM-RL, an MM-connection release request, without indication of release cause, is passed to the MM-sublayer, and the 
SMC entity enters the Idle state. 

In the case of a lower layer release, the SMC entity passes an MNSMS-ERROR Indication to SM-RL and then enters 
the Idle state. 

In all cases, if the timer TCI* is running, it is reset. 

Due to structure of message flow on S API and 3 it is possible that the CP-ACK of a short message transfer might not 
be received (e.g. due to hand over). If the first CP-ACK (acknowledging the CP-DATA that carried the first RPDU) is 
not received the reception of CP-DATA may be interpreted as the reception of the awaited CP-ACK and CP-DATA 

message. 
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5.4 Concatenating short message or notification transfers 

If an entity has more than one short message or notification to send, then it is useful to maintain the Radio Resource 
(RR) connection in between transfers for circuit switched GSM . For mobile terminated short messages this is simple 
because the network decides when, and whether, to release the RR connection. However, for mobile originated 
transfers, the network does not know whether or not the mobile has more messages to transfer. 

If another short message or a memory available notification is to be sent, an originating SMR entity in the MS may 
choose to continue to use the same RR connection. When the MS chooses to use the same RR connection, then: 

- the MS shall transmit a CM SERVICE REQUEST for the new CM connection before the final CP-ACK (e.g. the 
one that acknowledges the CP-DATA that carried the RP-ACK) for the old MM connection is transmitted; 

before transmission of the first CP-DATA on the new MM connection, the MS shall transmit the CP-ACK for 
the old MM connection; 

the Transaction Identifier used on the new MM connection shall be different to that used on the old MM 
connection; and 

the MS shall not initiate establishment of the new MM connection before the final CP-DATA (e.g. the one 
carrying the RP-ACK) has been received. 

NOTE: When an MS sends successive memory available notifications and/or mobile originated short messages 
on different RR connections, the MS is strongly recommended to use different Transaction Identifiers for 
the old and new MM connections. 

Due to the structure of message flow on SAPIs and 3 it is possible that the final CP-ACK of a short message transfer 
may not be received (e.g. due to transmission errors and/or hand overs). For mobile terminated transfers, if the CP-ACK 
is lost, the reception of a CP-DATA with a different transaction identifier and carrying an RPDU shall be interpreted as 
the implicit reception of the awaited CP-ACK followed by the reception of the new CP-DATA message. For mobile 
originated transfers, if the CP-ACK is lost, the reception of a CM SERVICE REQUEST followed by a CP-DATA with 
a different transaction identifier and carrying an RPDU shall be interpreted as the implicit reception of the awaited 
CP-ACK followed by the reception of the new CP-DATA message. 



SIVI-RL-procedures 



6.1 General 

This clause describes the procedures used by the SMR entity for short message and notification support on the Short 
Message Relay Layer. An SMR entity communicates with a corresponding peer entity using a CM-connection. 

Multiple CM-connections may be established at the same time, allowing parallel transactions. There is a functional one 
to one relation between the SMR entity and the SMC entity of the CM-sublayer. The descriptions of the procedures are 
related to one single transaction. 

The RL -procedures described in this subclause can only be performed if a CM-connection has been established between 
the mobile station and the network. Detailed SDL-diagrams for short message control on SM-RL are contained in annex 
D. 

6.2 Transition states of SIVIR entity 

The state transition diagram for the SMR entities on both MS-side and network side are contained in annex D. 

6.2.1 SIVIR-states at the IVIS-side of the radio interface 

The states described in this subclause are for a SMR entity in a MS, handling mobile originating- and mobile 
terminating short messages and notification transfer. 
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6.2.1.1 Idle (State 0) 

This state exists when the SMR entity is in idle mode, or when a short message or notification transfer ends in a normal 
or abnormal way. 

6.2.1 .2 Wait for RP-ACK (State 1 ) 

This state exists for mobile originating short message or notification transfer when the SMR has passed the RP-DATA 
or RP-SMMA to the SMC entity and set the timer TRIM. 

6.2.1 .3 Wait for RETRANS TIMER (State 4) 

This state exists for memory available notification when the SMR is waiting to retransmit the RP-SMMA message. 
Timer TRAM has been set. The possibility of an abort of the sending of the memory available notification by the 
SM-TL exists. No underlying connection exists. 

6.2.2 SMR-states at the network side of the radio interface 

The states described in this subclause are for a SMR entity in a MSC, handling mobile originating- and mobile 
terminating short message and notification transfer. 

6.2.2.1 Idle (State 0) 

This state exists when the SMR entity is in idle mode, or when a short message transfer or notification end in a normal 
or abnormal way. 

6.2.2.2 Wait for RP-ACK (State 1 ) 

This state exists for a mobile terminating short message transfer when the SMR has passed the RP-DATA message to 
the SMC entity and set the timer TRIN. 

6.2.2.3 Wait to send RP-ACK (State 3) 

The SMR entity will enter this state after passing a received RP-DATA or RP-SMMA message to RL and setting the 
timer TR2N. 

6.3 Short Message Relay procedures 

The procedures needed for short message and notification relaying are: 
TP Data Unit (TPDU) relay procedures; 
notification relay procedures; 
procedures for abnormal cases. 

6.3.1 TPDU relaying 

When the SMR entity is in the Idle state and receives a request from SM-TL to relay a TPDU, it forms and transfers the 
RP-DATA message (containing the TPDU), sets the timer TRl* and enters the state Wait for RP-ACK. 

Retransmission of RP data units by the CM-sublayer is described in clause 5. 

When the SMR entity is in the "Wait for RP-ACK" state, the following situations may occur: 

a) reception of an RP-ACK or RP -ERROR message (containing the same reference number as the transmitted 
RP-DATA message); 

b) reception of an error indication from the CM-sublayer; 
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c) the timer TRl* expires. 

In case a) or b), the timer TRl* is reset, a report indication is passed to SM-TL, a request to release the CM-connection 
is passed to CM-sublayer, and the SMR entity enters the Idle state. 

In case c), a request to abort the CM-connection is passed to the CM-sublayer, a report indication is passed to SM-TL, 
and the SMR entity enters the Idle state. 

When the SMR entity is in the Idle state and receives an MNSMS-EST-Ind containing a valid RP-DATA message, it 
passes the SMS-TPDU to the SM-TL, starts timer TR2*, and enters the state "Wait to Send RP-ACK". 

When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives the SM-RL-Report-Request, 
the timer TR2* is reset, the RP-message (RP-ACK or RP -ERROR) is generated and relayed to the peer entity, a 
CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state. 

When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives an error indication from the 
CM-sublayer, the timer TR2* is reset, a report indication is passed to the SM-TL and the SMR entity enters the Idle 

state. 

When the SMR entity is in the state "Wait to send RP-ACK" and the timer TR2* expires, the SMR entity passes a 
CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the SMR entity enters 
the Idle state. 

6.3.2 [spare] 

6.3.3 Notification relaying 
6.3.3.1 MS side 

6.3.3.1.1 Idle state 

When the SMR entity in the MS in the Idle state receives a request from the SM-TL to relay a notification to the 
network, it forms and transfers the RP-SMMA message, starts timer TRIM, and enters the state Wait for RP-ACK. 

6.3.3.1.2 Wait for RP-ACK state 

When the SMR entity in the MS is in the Wait for RP-ACK state and it receives either: 

an RP-ACK (containing the same reference number as the last transmitted RP-SMMA message); or 

an RP-ERROR (containing the same reference number as the last transmitted RP-SMMA message) with a 
permanent failure indication; or 

an error indication from the CP-sublayer; 

then the MS shall reset timer TRIM, pass a report indication to SM-TL, give a CM-connection release request to the 
CM-sublayer, and enter the Idle state. If set, timer TRAM and the RETRANS flag are also reset. 

When the SMR entity in the MS is in the Wait for RP-ACK state and either: 

it receives an RP-ERROR (containing the same reference number as the last transmitted RP-SMMA message) 
with a temporary failure indication; or 

timer TRIM expires; 

then the MS shall examine the RETRANS flag: 

if the RETRANS flag is set (i.e. no more transmissions of the RP-SMMA message are permitted) then: 

the MS shall pass a report indication to SM-TL, give a CM-connection release request to the CM-sublayer, 
reset the RETRANS flag, reset TRIM, and enter the Idle state. 
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If the RETRANS flag is not set (i.e. at least another transmission of the RP-SMMA message is currently 
permitted) then: 

the MS shall give a CM-connection release request to the CM-sublayer, set the RETRANS flag, reset TRIM, 
start timer TRAM and enter the Wait for Retrans Timer state. 

When the SMR entity in the MS is in the Wait for RP-ACK state and it receives an 

SM-RL-MEMORY-AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the MS shall set the RETRANS 
flag and reenter the Wait for RP-ACK state. 

6.3.3.1.3 Wait for RETRANS Timer state 

When the SMR entity in the MS is in the Wait for Retrans Timer state and timer TRAM expires then, the MS shall form 
and transfer an RP-SMMA message, start timer TRIM, and enter the state Wait for RP-ACK. The RP-Message 
Reference in this RP-SMMA message shall be different from that in the previous RP-SMMA message. 

When the SMR entity in the MS is in the Wait for Retrans Timer state and it receives an 
SM-RL-MEMORY-AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the MS shall reset the 
RETRANS flag, reset timer TRAM, pass a report indication to SM-TL, and enter the Idle state. 

6.3.3.2 Network side 

6.3.3.2.1 Idle state 

When the SMR entity in the network is in the Idle state and receives an MNSMS-EST-Ind containing a valid 
RP-SMMA message, it passes the SMS-TPDU to the SM-TL, starts timer TR2N, and enters the state "Wait to send 
RP-ACK". 

6.3.3.2.2 Wait to Send RP-ACK state 

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives the 
SM-RL-Report-Request, timer TR2N is reset, the RP-message (RP-ACK or RP -ERROR) is generated and relayed to 
the MS, a CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state. 

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives an error 
indication from the CM-sublayer, timer TR2N is reset, a report indication is passed to the SM-TL and the SMR entity 
enters the Idle state. 

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the timer TR2N expires, the SMR 
entity passes a CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the 
SMR entity enters the Idle state. 

6.3.4 Abnormal cases 

Format errors etc.: 

If the SMR entity upon receipt of an RP-DATA or RP-SMMA message detects an erroneous condition which it 
can act on, (e.g. format errors, invalid parameters etc.) it shall return an RP -ERROR message with an appropriate 
cause value and possibly extended diagnostic information, release or abort the CM-connection, and enter the Idle 
state. 



7 Message functional definitions and content 

7.1 General 

The notation used is as used in 3GPP TS 04.08/clause 9, and each definition includes: 
a) A brief description of the message direction and use. 
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b) A table listing the information elements in the order of their appearance in the message. For each information 
element the table indicates: 

1) A reference to the (sub)clause/Technical Specification describing the information element. 

2) The presence requirement indication (M, C, or O) for the IE as defined in 3GPP TS 04.07. 

3) The format of the information element (T, V, TV, LV, TLV) as defined in 3GPP TS 04.07. 

4) The length of the information element (or permissible range of lengths), in octets, in the messages. 

7.2 Messages for short message or notification transfer on CIV! 

This subclause describes the functional definition and content of the messages sent between two SMC entities. 
There are three messages defined: CP-DATA, CP-ACK and CP-ERROR. 



7.2.1 



CP-DATA 



The CP-DATA message is sent between an MSC and an MS, in both directions. The message contains the user data to 
be relayed between the CM-users, and associated parameters. See table 7.1/ 3GPP TS 04.11. 

Table 7.1/3GPP TS 04.11 : CP-DATA message content 





Information element 


Reference 


Presence 


Format 


Length 




Protocol discriminator 


3GPP TS 04.07 


M 


V 


1/2 octet 




Transaction identifier 


3GPP TS 04.07 


M 


V 


1/2 octet 




l\/lessage type 


Subclause 8.1.3 


M 


V 


1 octet 




CP-User data 


Subclause 8.1.4.1 


M 


LV 


< 249 octets 



7.2.2 CP-ACK 

The CP-ACK message is sent between an MSC and an MS, in both directions, and is used to acknowledge the reception 
of a CP-DATA message. 



See table 7.2/3GPP TS 04.11. 



Table 7.2/3GPP TS 04.1 1 : CP-ACK message content 





Information element 


Reference 


Presence 


Format 


Length 




Protocol discriminator 


3GPP TS 04.07 


M 


V 


1/2 octet 




Transaction identifier 


3GPP TS 04.07 


M 


V 


1/2 octet 




Message type 


Subclause 8.1.3 


M 


V 


1 octet 



7.2.3 CP-ERROR 

The CP-ERROR message is sent between an MSC and an MS, in both directions, and used to convey error information. 
See table 7.3/3GPP TS 04.11. 

Table 7.3/3GPP TS 04.1 1 : CP-ERROR message content 





Information element 


Reference 


Presence 


Format 


Length 




Protocol discriminator 


3GPP TS 04.07 


M 


V 


1/2 octet 




Transaction identifier 


3GPP TS 04.07 


M 


V 


1/2 octet 




IVIessage type 


Subclause 8.1.3 


M 


V 


1 octet 




CP-Cause 


Subclause 8.1.4.2 


M 


V 


1 octet 
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7.3 Messages for short message and notification transfer on 
SIVI-RL 

This subclause describes the functional definition and content of the messages sent between two SMR entities. 
There are 4 messages defined: RP-DATA, RP-SMMA, RP-ACK and RP-ERROR. 

7.3.1 RP-DATA 

A phase 2 entity shall not reject a RP-DATA message where both address elements have a length greater than 0. 



7.3.1.1 



RP-DATA (Network to Mobile Station) 



This message is sent in MSC -> MS direction. The message is used to relay the TPDUs. The information elements are 
in hne with 3GPP TS 03.40. See table 7.4/3GPP TS 04. 11. 

Table 7.4/3GPP TS 04.11 : RP-DATA message content 





Information element 


Reference 


Presence 


Format 


Length 




RP-Message Type 


Subclause 8.2.2 


M 


V 


3 bits 




RP-Message Reference 


Subclause 8.2.3 


M 


V 


1 octet 




RP-Originator Address 


Subclause 8.2.5.1 


M 


LV 


1-12 octets 




RP-Destination Address 


Subclause 8.2.5.2 


M 


LV 


1 octet 




RP-User Data 


Subclause 8.2.5.3 


M 


LV 


< 233 octets 



7.3.1.2 



RP-DATA (Mobile Station to Network) 



This message is sent in MS -> MSC direction. The message is used to relay the TPDUs. The information elements are 
in hne with 3GPP TS 03.40. See table 7.5/3GPP TS 04. 11. 

Table 7.5/3GPP TS 04.11 : RP-DATA message content 





Information element 


Reference 


Presence 


Format 


Length 




RP-Message Type 


Subclause 8.2.2 


M 


V 


3 bits 




RP-Message Reference 


Subclause 8.2.3 


M 


V 


1 octet 




RP-Originator Address 


Subclause 8.2.5.1 


M 


LV 


1 octet 




RP-Destination Address 


Subclause 8.2.5.2 


M 


LV 


1-12 octets 




RP-User Data 


Subclause 8.2.5.3 


M 


LV 


< 233 octets 



7.3.2 



RP-SIVIIVIA 



This message is sent by the mobile station to relay a notification to the network that the mobile has memory available to 
receive one or more short messages. The information elements are in line with 3GPP TS 03.40. See table 7.6/3GPP 
TS04.il. 

Table 7.6/3GPP TS 04.1 1 : RP-SMMA message content 





Information element 


Reference 


Presence 


Format 


Length 




RP-Message Type 


Subclause 8.2.2 


M 


V 


3 bits 




RP-Message Reference 


Subclause 8.2.3 


M 


V 


1 octet 



7.3.3 RP-ACK 

This message is sent between the MSC and the mobile station in both directions and used to relay the acknowledgement 
of a RP-DATA or RP-SMMA message reception. The information elements are in line with 3GPP TS 03.40. See table 
7.7/3GPP TS04.il. 
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Table 7.7/3GPP TS 04.1 1 : RP-ACK message content 



lEI 


Information element 


Reference 


Presence 


Format 


Length 




RP-Message Type 


Subclause 8.2.2 


M 


V 


3 bits 




RP-Message Reference 


Subclause 8.2.3 


M 


V 


1 octet 


41 


RP-User Data 


Subclause 8.2.5.3 





TLV 


< 234 octets 



7.3.4 RP-ERROR 

This message is sent between the MSC and the mobile station in both directions and used to relay an error cause from 
an erroneous short message or notification transfer attempt. The information elements are in line with 3GPP TS 03.40. 
See table 7.8/3GPP TS 04.11. 

The contents of the cause field are given in subclause 8.2.5.4. 

Table 7.8/3GPP TS 04.1 1 : RP-ERROR message content 



IE! 


Information element 


Reference 


Presence 


Format 


Length 




RP-Message Type 


Subclause 8.2.2 


M 


V 


3 bits 




RP-Message Reference 


Subclause 8.2.3 


M 


V 


1 octet 




RP-Cause 


Subclause 8.2.5.4 


M 


LV 


2-3 octets 


41 


RP-User Data 


Subclause 8.2.5.3 





TLV 


< 234 octets 





8 Message format and information elements coding 

8.1 CP-messages 
8.1.1 General 

The message format and information elements coding is in line with 3GPP TS 04.07 and 3GPP TS 04.08. 
The message shall consist of the following parts: 

a) protocol discriminator; 

b) transaction identifier; 

c) message type; 

d) other required information elements. 

This organization is illustrated in the example shown in figure 8.1/04.11 



8 7 6 5 


4 3 2 


1 


Transaction Id. 


Protocol Discr. 


Message Type 


Other Informs 


tion Elements 





Figure 8.1/3GPPTS 04.11 

8.1 .2 Protocol Discriminator and Transaction Identifier 

The Protocol Discriminator and Transaction Identifier is described in 3GPP TS 04.07. 



£75/ 



3GPP TS 04.11 version 7.1.0 Release 1998 



30 



ETSI TS 100 942 V7.1.0 (2000-09) 



8.1.3 Message type 

The purpose of the message type, together with the protocol discriminator, is to identify the function of the message 
being sent. The coding of message types is shown in table 8. 1/3GPP TS 04. 1 1 . 

Table 8.1/3GPP TS 04.1 1 : Message types for short message and notification transfer on CIV! 



8 


7 6 


5 


4 


3 


2 1 



















1 


CP-DATA 














1 





CP-ACK 








1 











CP-ERROR 



8.1 .4 Other required information elements 



8.1.4.1 



CP-User data element 



The CP-User data element is used to carry the RPDU. It has an information element identifier, a length indicator and a 
data field. The data field will contain the RPDUs. The maximum length of the data field is 248 octets. The layout is 
indicated in figure 8.2/3GPP TS 04. 1 1. 



8 


7 


6 5 4 3 2 


1 









CP-User Data lEI 


1 


Length indicator 


RPDU 

Maximum length 248 octets 



1 octet 
1 octet 

? octet 



Figure 8.2/3GPP IS 04.1 1 : CP-User data element layout 



8.1.4.2 



CP-Cause element 



This element is included in the CP-ERROR message, the layout is given in figure 8.3/3GPP TS 04.1 1. The error causes 
are listed in table 8.2/3GPP TS 04.1 1. 



8 


7 


6 


5 4 3 


2 


1 












CP-Cause lEI 


1 








Cause value 



1 octet 
1 octet 



Figure 8.3/3GPP TS 04.11 : CP-Cause element layout 



Table 8.2/3GPP TS 04.1 1 : Content and coding of CP-Cause 



Cause value 


Cause nr. 


Cause 








7654321 


# 




0010001 


17 


Network failure 


0010 110 


22 


Congestion 


1010001 


81 


Invalid Transaction Identifier value 


1011111 


95 


Semantically incorrect message 


1 100000 


96 


Invalid mandatory information 


1 100001 


97 


Message type non-existent or not implemented 
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1 100010 


98 


Message not compatible with the short message protocol state 


1 10001 1 


99 


Information element non-existent or not implemented 


1101111 


111 


Protocol error, unspecified 








All other cause values shall be treated as cause number 111. 



8.2 RP-messages 



8.2.1 General 

The message shall consist of the following parts: 

a) message type indicator; 

b) message reference; 

c) other required information elements. 

This organization is illustrated in the example shown in figure 8.4/04. 1 1 : 



8 


7 


6 5 4 


3 2 1 








spare 



MTI 


Message reference 






Other Information Eler 


nents 



Figure 8.4/3GPPTS 04.11 

8.2.2 Message type indicator (MTI) 

The message type indicator, MTI, is a 3-bit field, located in the first octet of all RP-messages. The coding of the MTI is 
defined by table 8.3/3GPP TS 04.1 1. 

Table 8.3/3GPP TS 04.1 1 : Coding of lUlessage Type Indicator 



Bit value 


Direction 


RP-Message 


32 1 






000 


ms-> n 


RP-DATA 


000 


n -> ms 


Reserved 


00 1 


ms -> n 


Reserved 


001 


n -> ms 


RP-DATA 


01 


ms-> n 


RP-ACK 


01 


n -> ms 


Reserved 


01 1 


ms -> n 


Reserved 


01 1 


n -> ms 


RP-ACK 


1 00 


ms -> n 


RP-ERROR 


1 00 


n -> ms 


Reserved 


1 1 


ms -> n 


Reserved 


1 01 


n -> ms 


RP-ERROR 


1 1 


ms -> n 


RP-SMMA 


1 1 


n -> ms 


Reserved 


1 1 1 


ms -> n 


Reserved 


1 1 1 


n -> ms 


Reserved 
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8.2.3 Message reference 

The message reference field contains a sequence number in the range through 255, and is used to Hnk an RP-ACK 
message or RP -ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. 

8.2.4 [Spare] 

8.2.5 Other required information elements 



8.2.5.1 



Originator address element 



In the case of MT transfer this element contains the originating Service Centre address. 

The RP-Originator Address information element is coded as shown in figure 8.5/3GPP TS 04. 11. 

The RP-Originator Address is a type 4 information element. In the network to mobile station direction the minimum 
value of the length octet is 2 and the maximum value is 1 1 . In the mobile station to network direction the value of the 
length octet of the element is set to 0. 



1 





RP-Originator Address lEI 


Length of RP-Originator Address contents 


1 ext 


type of number 


Numbering plan 
identification 


Number digit 2 


Number digit 1 


Number digit 4 


Number digit 3 







octet 1 

octet 2 
octet 3 

octet 4 
octet 5 



Figure 8.5/3GPP TS 04.1 1 : RP-Originator Address information element 

If the RP-Originator Address contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end 
mark coded as "1111". 

The contents of octets 3, 4, etc. are the same as those defined for the Called Party BCD Number IE defined in 3GPP 
TS 04.08. 

8.2.5.2 Destination address element 

In the case of MO transfer, this element contains the destination Service Centre address. 

The RP-Destination Address information element is coded as shown in figure 8.6/3GPP TS 04. 1 1 . 

The RP-Destination Address is a type 4 information element. In the mobile station to network direction the minimum 
value of the length octet is 2 and the maximum value is 1 1 . In the network to mobile station direction, the value of the 
length octet of the element is set to 0. 



7 



1 





RP-Destination Address number lEI 


Length of RP-Destination Address contents 


1 ext 


type of number 


Numbering plan 
identification 


Number digit 2 


Number digit 1 


Number digit 4 


Number digit 3 









octet 1 
octet 2 
octet 3 

octet 4 
octet 5 
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L 



± 



J 



Figure 8.6/3GPP TS 04.11 : RP-Destination Address information element 

The number digit(s) in octet 4 precede the digit(s) in octet 5 etc. The number digit which would be entered first is 
located in octet 4, bits 1 to 4. 

If the RP-Destination Address contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end 
markcodedas"llll". 

Since the information element contains the complete RP-Destination Address there is no need for an additional 
complete indication. 

The contents of octets 3, 4, etc. are the same as those defined for the Called Party BCD Number IE defined in 3GPP 
TS 04.08. 



8.2.5.3 



RP-User data element 



The RP-User data field contains the TPDU and is mandatory in a RP-DATA message. RP-User data is also optionally 
carried in an RP -Error message. In a RP DATA message, the element has a variable length, up to 233 octets, and in a 
RP ERROR and in a RP ACK message the length is up to 234 octets. 

RP-User data in an RP-Error message is conveyed as diagnostic information within the "SM-DeliveryFailureCause" 
response to a MAP Forward-Short-Message procedure (see 3GPP TS 09.02). The diagnostic information may be sent in 
both directions, and shall always be forwarded by the MSC if it is received. 



8 


7 6 5 4 3 


2 


1 





10 
RP-User Data lEI 





1 


Length indicator 


TPDU 

Maximum length 232 octets 



1 octet 
1 octet 



Figure 8.7/3GPP TS 04.1 1 : RP-User data element layout 



8.2.5.4 



RP-Cause element 



This element is a variable length element always included in the RP-ERROR message, conveying a negative result of a 
RP-DATA message transfer attempt or RP-SMMA notification attempt. The element contains a cause value and 
optionally a diagnostic field giving further details of the error cause. 

The coding of the cause value is given in table 8.4/3GPP TS 04. 11. The mapping between error causes in 3GPP 

TS 04. 1 1 and 3GPP TS 09.02 (MAP) is specified in 3GPP TS 03.40. Parameters included in the return error from MAP 

(e.g. System Failure) are mapped directly into the diagnostic field. 



8 


7 


6 5 4 


3 


2 


1 





1 




RP-Cause lEI 





1 





Length indicator 


Oext 


Cause value 
Cause value 


Diagnostic field 



1 octet 
1 octet 
1 octet 

1 octet * 



Figure 8.8/3GPP TS 04.11 : RP-Cause element layout 
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Table 8.4/3GPP TS 04.11 (part 1): Cause values that may be contained in an RP-ERROR message 

in a mobile originating SM-transfer attempt 



Cause value 


Cause 


Cause 


Class value 


number 










7654321 


# 




0000001 


1 


Unassigned (unallocated) number 


0001000 


8 


Operator determined barring 


0001010 


10 


Call barred 


0001011 


11 


Reserved 


0010 101 


21 


Short message transfer rejected 


0011011 


27 


Destination out of order 


0011100 


28 


Unidentified subscriber 


0011101 


29 


Facility rejected 


0011110 


30 


Unknown subscriber 


100110 


38 


Network out of order 


101001 


41 


Temporary failure 


101010 


42 


Congestion 


10 1111 


47 


Resources unavailable, unspecified 


110010 


50 


Requested facility not subscribed 


1000 101 


69 


Requested facility not implemented 


1010001 


81 


Invalid short message transfer reference value 


1011111 


95 


Semantically incorrect message 


1 100000 


96 


Invalid mandatory information 


1 100001 


97 


Message type non-existent or not implemented 


1100010 


98 


Message not compatible with short message protocol 
state 


1100011 


99 


Information element non-existent or not implemented 


110 1111 


111 


Protocol error, unspecified 


1111111 


127 


Interworking, unspecified 








All other cause values shall be treated as cause number 41 , "Temporary Failure". 



Table 8.4/3GPP TS 04.1 1 (part 2): Cause values that may be contained in an RP-ERROR message in a 

mobile terminating SM-transfer attempt 



Cause value 


Cause 


Cause 


Class value 


number 










765432 1 


# 




0010110 


22 


Memory capacity exceeded 


10 10001 


81 


Invalid short message transfer reference value 


10 11111 


95 


Semantically incorrect message 


1100000 


96 


Invalid mandatory information 


110000 1 


97 


Message type non-existent or not implemented 


1100010 


98 


Message not compatible with short message protocol state 


1100011 


99 


Information element non-existent or not implemented 


1101111 


111 


Protocol error, unspecified 








All other cause values shall be treated as cause number 111, "Protocol error, unspecified". 
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Table 8.4/3GPP TS 04.1 1 (part 3): Cause values that may be contained in an RP-ERROR message in a 

memory available notification attempt 



Cause value 


Cause 


Cause 


Cause 


Class value 


number 


type 












7654321 


# 






0011110 


30 


P 


Unknown Subscriber 


100110 


38 


T 


Network out of order 


101001 


41 


T 


Temporary failure 


101010 


42 


T 


Congestion 


10 1111 


47 


T 


Resources unavailable, unspecified 


1000 101 


69 


P 


Requested facility not implemented 


1011111 


95 


P 


Semantically incorrect message 


1 100000 


96 


P 


Invalid mandatory information 


1 100001 


97 


P 


IVIessage type non-existent or not implemented 


1100010 


98 


P 


Message not compatible with short message protocol state 


1100011 


99 


P 


Information element non-existent or not implemented 


110 1111 


111 


P 


Protocol error, unspecified 


1111111 


127 


P 


Interworking, unspecified 










All other cause values are treated as cause number 41 , "Temporary failure". 




Each cause is classified as "Temporary" or "Permanent", as indicated by T and P respectively in the cause type 
column. 



Handling of unknown, unforeseen, and erroneous 
protocol data 



9.1 



General 



This subclause specifies procedures for handling of unknown, unforeseen, and erroneous protocol data by the receiving 
entity. These procedures are called "error handling procedures", but in addition to providing recovery mechanisms for 
error situations they define a compatibility mechanism for future extensions of the protocols. 

Most error handling procedures are mandatory for the MS but optional for the network. Detailed error handling 
procedures in the network are implementation dependent and may vary from PLMN to PLMN. 

In this subclause the following terminology is used: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved", 
or if its value part violates rules. However it is not a syntactical error that a type 4 IE specifies in its length 
indicator a greater length than defined. 

A message is defined to have semantically incorrect contents if it contains information which, possibly 
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural 
part of3GPP TS04.il. 



9.2 CP Error Handling 



Upon receiving a CP-ERROR message the SMC-CS entity (in any state) shall pass an error indication to SM-RL, pass 
an MM-connection release request to the MM-sublayer, and enter the Idle State. 

After sending a CP-ERROR message the SMC-CS entity (in any state) shall pass an MM-connection release request to 
the MM sublayer and then enter the Idle State. 
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Upon receiving a CP-ERROR message the SMC-GP entity (in any state) shall pass an error indication to SM-RL and 
enter the Idle State. 

After sending a CP-ERROR message the SMC-GP entity (in any state) shall enter the Idle State. 

9.2.1 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored, see 3GPP TS 04.07. 

9.2.2 Unknown or unforeseen transaction identifier 

The Mobile Station shall ignore a CP message (CP-DATA, CP-ACK, CP-ERROR) received with TI value "111". 
Whenever a CP-ACK message is received specifying a Transaction Identifier which is not associated with an active SM 
transfer, the mobile station shall discard the message and return a CP-ERROR message with cause #81, "Invalid 
Transaction Identifier" using the received Transaction Identifier, if an appropriate connection exists. The Mobile Station 
shall ignore a CP-ERROR message that is received specifying a Transaction Identifier which is not associated with an 
active SM transfer. The Mobile Station shall ignore a CP-DATA message that is received specifying a Transaction 
Identifier which is not associated with an active SM transfer and with transaction identifier flag set to "1". 

The same procedures may apply to the network. 

9.2.3 Unl^nown or unforeseen message type 

If the Mobile Station receives a message with message type not defined for the PD or not implemented by the receiver, 
it shall ignore the message and return a CP-ERROR message with cause #97 "message type non-existent or not 
implemented", if an appropriate connection exists. 

NOTE: A message type not defined for the PD in the given direction is regarded by the receiver as a message 
type not defined for the PD, see 3GPP TS 04.07. 

If the Mobile Station receives a message not consistent with the protocol state, the Mobile Station shall ignore the 
message and return a CP-ERROR message with cause #98 "Message type not compatible with the short message 
protocol state", if an appropriate connection exists. 

The network may follow the same procedures. 

9.2.4 Non-semantical mandatory information element errors 

When on receipt of a message: 

an "imperative message part" error; or 

a "missing mandatory IE" error. 

is diagnosed or when a message containing a syntactically incorrect mandatory IE is received, the mobile station shall 
proceed as follows. 

When the corresponding SM transfer is not seen as successfully transferred, i.e. the transaction is not completed, the 
mobile station shall ignore the message and return a CP-ERROR message with cause #96 "invalid mandatory 
information", if an appropriate connection exists. 

When the SM transfer is seen as successfully transferred, the mobile station shall ignore the message and enter the Idle 
State. 

In the case that the message received is a CP-ERROR message, the mobile station shall ignore the message and enter 
the Idle State. 

The network may follow the applicable procedures defined in this subclause. 
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9.2.5 Messages with semantically incorrect contents 

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of 3GPP 
TS 04. 1 1 are performed. If however no such reactions are specified, the mobile station shall proceed as follows: 

When the corresponding SM transfer is not seen as successfully transferred, the mobile station shall ignore the 
message and return a CP -ERROR message with cause value #95 "semantically incorrect message", if an 
appropriate connection exists. 

When the SM transfer is seen as successfully transferred, the mobile station shall ignore the message and enter 
the Idle State. 

In the case that the message received is a CP-ERROR message, the mobile station shall ignore the message and 
enter the Idle State. 

The network may follow the same procedure. 



9.3 RP Error Handling 



Upon receiving or sending an RP-ERROR message the SMR entity shall behave as described in the procedural 
description in clause 6. 

9.3.1 Message too sinort 

When a message is received that is too short to contain a complete message type information element and Message 
Reference, that message shall be ignored. 

9.3.2 Unl^nown or unforeseen Message Reference 

Whenever any RP-ACK message is received specifying a Message Reference which is not associated with an active SM 
transfer, the mobile station shall discard the message and return an RP-ERROR message with cause #81, "Invalid short 
message transfer reference value" using the received Message Reference, if an appropriate connection exists. 

When an RP-ERROR message is received specifying a Message Reference which is not associated with an active SM 
transfer, the mobile station shall discard the message. 

When the mobile station's SMR entity is not in the Idle state, and it receives an RP-DATA message specifying a 
Message Reference which is not associated with the active SM transfer, then it shall either: 

send an RP-ERROR message with cause #81, "Invalid short message transfer reference value" using the received 
Message Reference, if an appropriate connection exists; or 

behave as described below for the receipt of an message not consistent with the protocol state. 

The same procedures may apply to the network. 

9.3.3 Unknown or unforeseen message type 

If the Mobile Station receives a RP-message indicating a value of the message type indicator (MTI) defined as reserved, 
it shall ignore the message and return an RP-ERROR message with cause #97 "message type non-existent or not 
implemented", if an appropriate connection exists. 

If the Mobile Station receives a message (except RP-ERROR) not consistent with the protocol state, the Mobile Station 
shall ignore the message and return a RP-ERROR message with cause #98 "Message type not compatible with Short 
Message protocol state", if an appropriate connection exists. 

If the Mobile Station receives an RP-ERROR message not consistent with the protocol state, the Mobile Station shall 
ignore the message. 

The network may follow the same procedures. 
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9.3.4 Non-semantical mandatory information element errors 

When on receipt of a message: 

an "imperative message part" error; or 

a "missing mandatory IE" error; 

is diagnosed or when a message containing a syntactically incorrect mandatory IE is received, the mobile station shall 
(except for the case of a reserved value of the MTI as defined above) proceed as follows: 

when the message is an RP-DATA or RP-ACK, the mobile station shall ignore the message and return an 
RP -ERROR message with cause #96 "invalid mandatory information", if an appropriate connection exists; 

when the message is an RP-ERROR, the mobile station shall treat the message as an RP -ERROR message 
carrying RP-Cause value 111 without any diagnostic field, and with no RP-User Data. 

The network may follow the applicable procedures defined in this subclause. 

9.3.5 Messages with semantically incorrect contents 

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of 3GPP 
TS 04. 11 are performed. If however no such reactions are specified then: 

if the message was not an RP-ERROR message, the MS shall ignore the message and return an RP-ERROR 
message with cause value #95 "semantically incorrect message", if an appropriate connection exists; while 

if the message was an RP-ERROR message, the mobile station shall treat the message as an RP-ERROR 
message carrying RP-Cause value #111 without any diagnostic field, and with no RP-User Data. 

The network may follow the same procedure. 



10 Timers 

The present document places the following requirements on the timers described in this ETS: 
timer TRIM shall be greater than 35 seconds and less than 45 seconds; 
the value of timer TRAM shall be greater than 25 seconds and less than 35 seconds; 
timer TR2M shall be greater than 12 seconds and less than 20 seconds. 
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Annex A (informative): 
Arrow diagrams 

Arrow diagram Al : 



The diagram shows CS GSM MO-message transfer by means of interlayer service primitives and the actual 
messages being transferred between the layer entities 

Arrow diagram A2: 

The diagram shows CS GSM MT-messaging by means of interlayer service primitives and the actual messages 
being transferred between the layer entities 

Arrow diagram A5: 

The diagram shows GPRS MO-message transfer by means of interlayer service primitives and the actual 
messages being transferred between the layer entities. 

MNSMS -primitives indicate services provided by CM to SM-RL. 

LLSMS-primitives indicate services provided by LLC to CM. 

- CP-DATA is the CM-message carrying SM-RP data units. 

- CP-ACK acknowledge CP-DATA reception on CM. 

Arrow diagram A6: 

The diagram shows GPRS MT-message transfer by means of interlayer service primitives and the actual 
messages being transferred between the layer entities. 

MNSMS -primitives indicate services provided by CM to SM-RL. 

LLSMS-primitives indicate services provided by LLC to CM. 

- CP-DATA is the CM-message carrying SM-RP data units. 

- CP-ACK acknowledge CP-DATA reception on CM. 
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GPRS Mobile Originated Messaging on CM-sublayer 



SM-RL 



Mobile Station Side 

CM 



MNSMS-EST-Req (RP-DATA) 



/INSMS-DATA-Ind (RP-ACK) 



MNSMS-REL-req 



LC 



LL-UNITDATA- Req 
(TLLI, CP DATA) 



LL-UNITDATA - Ind 
(TLLI, CP ACK) 



LL-UNITDATA - Ind 
(TLLI, CP DATA) 



LL-UNITDATA - Req 
(TLLI, CP ACK) ^ 



LLC 



LLC-UI 
(CP DATA) 



LLC-UI 
(CP ACK) 



LLC-UI 
(CP DATA) 



LLC-UI 
(CP ACK) 



Network Side 

CM 



LL-UNITDATA- Ind 
(TLLI, CP DATA) 



VINSMS-EST-Ind (RP-DATA) 



LL-UNITDATA- Req 
(TLLI, CP ACK) 



LL-UNITDATA - Req 
(TLLI, CP DATA) 



LL-UNITDATA - Ind 
(TLLI, CP ACK) 



SM-RL 



/INSMS-DATA-Req (RP-ACK) 



MNSMS-REL-req 



Arrow diagram A5 
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GPRS Mobile Terminated Messaging on CM-sublayer 



SM-RL 



Mobile Station Side 

CM 



LLC 



LLC 



Network Side 

CM 



SM-RL 



MNSMS-EST- Ind (RP DATA) 



MNSMS-DATA- Req (RP ACK) 



MNSMS-REL-req 



LL-UNITDATA-Ind 
(TLLI, CP DATA) 



LL-UNITDATA - Req 
(TLLI, CP ACK) 



LL-UNITDATA - Req 
(TLLI. CP DATA) ^ 



LL-UNITDATA-Ind 
(TLLI, CPACK) 



LLC-UI 
(CP DATA) 



LLC-UI 
(CP ACK) 



LLC-UI 
(CP DATA) 



LLC-UI 
(CP ACK) 



LL-UNITDATA - Req 
(TLLI. CP DATA) 



LL-UNITDATA - Ind 
(TLLI, CP ACK) 



LL-UNITDATA - Ind 
(TLLI, CP DATA) 



LL-UNITDATA - Req 
^ (TLLI. CP ACK) 



MNSMS-EST- Req (RP DATA) 



MNSMS-DATA- Ind (RP ACK) 



MNSMS-REL-req 



Arrow diagram A6 
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Annex B (normative): 
SDL-description of the CM-layer 

B.1 Introduction 

This annex contains an SDL-description of the Connection Management Sublayer in terms of the Short Message 
Service Support. The CM- sublayer provides services to Short Message Relay Layer. 

The SDLs contain a mixture of peer to peer messages and conceptual primitives between the layers SM-RL, CM, MM 
and LLC, as viewed by the SMC entities. SDL-1/2/3 show the CS GSM SMC entity on MS-side for Mobile Originated 
(MO) short message transfer, SDL-4/5/6 show the CS GSM SMC entity on MS-side for Mobile Terminated (MT) short 
message transfer, SDL-7/8/9 show the CS GSM SMC entity on the network side for Mobile Originated (MO) short 
message transfer, and SDL-10/1 1/12 show the CS GSM SMC entity on the network side for Mobile Terminated (MT) 
short message transfer. 

SDL-13/14/15 show the GPRS SMC entity on MS-side for Mobile Originated (MO) short message transfer, 
SDL-16/17/18 show the GPRS SMC entity on MS-side for Mobile Terminated (MT) short message transfer, 
SDL- 19/20/21 show the GPRS SMC entity on the network side for Mobile Originated (MO) short message transfer, and 
SDL-22/23/24 show the GPRS SMC entity on the network side for Mobile Terminated (MT) short message transfer. 

The lower layers (below MM and LLC) are transparent to an SMC entity. 



MO-IDLE 




MNSMS- 
EST-Req 
RP DATA) 



MO-SMC-GP entity on MS-side for GPRS 
SDL-13 
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MO-Wait 

for 

CPACK 



CRACK 



Reset TC1M 



Set retx = Zero 



MO-Wait 

for 

CP DATA 



TC1M 




No 



MNSMS- 
ERROR- 
Ind 



Set retx = Zero 



MO-IDLE 



retx = retx+1 



MO-SMC-GP entity on MS-side for GPRS 
SDL-14 



£75/ 



3GPP TS 04.11 version 7.1.0 Release 1998 



44 



ETSI TS 100 942 V7.1.0 (2000-09) 



MO-Wait 

for 

CP DATA 



CP DATA 






MNSMS- 
ABORT- 
Req 



MNSMS- 

DATA- 

nd (RP ACK) 



CP ERROR 



CPACK 



> 




MO-IDLE 



MO-SMC-GP entity on MS-side for GPRS 
SDL-15 




MO-SMC-GP entity on MS-side for GPRS 
State transition diagram 
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MT-IDLE 



LL- 

UNITDATA- 
lnd-{RP DATA)\. 



V 



<^ DATA- 
Xjnd (RP data; 



CPACK 




1 J MT - Wait 
for 
BRACK 



MT-SMC-GP entity on MS-side for GPRS 
SDL-16 



MT-Wait 

for 

BRACK 



\. MNSMS- 
>DATA-Beq 
y^ (BRACK) 





MNSMS- 
ABOBT- 
Beq 



CP EBBOR 



MT-IDLE 



MT-SMC-GP entity on MS-side for GPRS 
SDL-17 
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MT-Wait 

for 

CPACK 



CPACK 




Reset TC1 M 



Set retx = Zero 



MT-IDLE 



TC1M 



No 



Oetx = 


= max>- 
Yes 








X MNSMS- 
<' ERROR- 
\ Ind 




retx = retx+1 








i 


Set retx = Zero 


6 



MT-SMC-GP entity on MS-side for GPRS 
SDL-18 
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MT-SMC-GP entity on MS-side for GPRS 
State transition diagram 
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MT-Wait 

for 

RPACK 




MNSMS- 
DATA-Req 
RP ACK) 




MNSMS- 
ABORT- 
Req 



CP ERROR 



MT-IDLE 



MO-SMC-GP entity on Network side for GPRS 
SDL-20 
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for 

CPACK 
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Set retx = Zero 



MO-IDLE 
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MO-SMC-GP entity on Network side for GPRS 
SDL-21 
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MO-SMC-GP entity on Network-side for GPRS 
State transition diagram 



MT-IDLE 




MNSMS- 
EST-Req 
(RP DATA) 



IVIT-SIUIC-GP entity on Networl<-side for GPRS 
SDL-22 
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MT-Wait 

for 

CP DATA 



CP DATA 






MNSMS- 
ABORT- 
Req 



NSMS- 
DATA- 
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CP ERROR 



CPACK 
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MT-IDLE 



MT-SMC-GP entity on Network-side for GPRS 
SDL-24 




IVIT-SIUIC-GP entity on Network-side for GPRS 
State transition diagram 
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Annex C (informative): 
Arrow diagrams 

Arrow diagram C 1 : 



The diagram reflects MO-message transfer by means of interlayer service primitives and the actual messages being 
transferred between the layer entities. 

SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note). 

MNSMS -primitives indicate services provided by CM to SM-RL. 

- RP-DATA is the SM-RL message carrying SM-TP data units. 

- RP-ACK acknowledges RP-DATA reception on SM-RL. 

Arrow diagram C2: 

The diagram reflects MT-messaging by means of interlayer service primitives and the actual messages being transferred 
between the layer entities. 

SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note). 

- MNSMS-primitives indicate services provided by CM to SM-RL. 

- RP-DATA is the SM-RL message carrying SM-TP data units. 

- RP-ACK acknowledges RP-DATA reception on SM-RL. 

Arrow diagram C3: 

The diagram reflects memory available notification transfer by means of interlayer service primitives and the actual 
messages being transferred between the layer entities. 

SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note). 

MNSMS-primitives indicate services provided by CM to SM-RL. 

RP-SMMA is the SM-RL message indicating that the mobile has memory available to receive one or more short 

messages. 

- RP-ACK acknowledges RP-SMMA reception on SM-RL. 

RP-ERROR reports a failure in the notification procedure on the network side. 
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Arrow diagram C4: 

The diagram reflects the abort of any retransmission of a memory available notification by SM-RL by means of the 
SM-RL-MEMORY- AVAILABLE interlayer service primitive request with the SM-MEM-NOTIF- ABORT parameter 
present. The use of this primitive and the associated parameter are, of course, local to the mobile station. 

SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (note). 

MNSMS -primitives indicate services provided by CM to SM-RL. 

RP-SMMA is the SM-RL message indicating that the mobile has memory available to receive one or more short 

messages. 

- RP-ACK acknowledges RP-SMMA reception on SM-RL. 

RP-ERROR reports a failure in the notification procedure on the network side. 

NOTE: The SM-RL being the upper layer in the MSC, an interworking function between SM-RL-procedures and 
MAP -procedure is necessary. The term "RL" is used in the diagrams to indicate this function (see figure). 




SM-RL 
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Mobile Originated lUlessaging on SIUI-RL 
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Arrow diagram CI 



£75/ 



3GPP TS 04.11 version 7.1.0 Release 1998 



56 



ETSI TS 100 942 V7.1.0 (2000-09) 



Mobile Terminated Messaging on SM-RL 
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Arrow diagram C2 
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Memory Available Notification on SM-RL 
Mobile Station Side Network side 
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Arrow diagram C3 
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Memory Available Notification Abort on SM-RL 
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Annex D (normative): 

SDL-description of the short message relay layer 

D.1 Introduction 

This annex contains an SDL-description of the Short Message Relay Layer in terms of the Short Message Service 
Support. The Short Message Relay Layer provides services to Short Message Transfer Layer. 

The SDLs contain a mixture of peer to peer messages and conceptual primitives between the layers SM-TL, SM-RL and 
CM, as viewed by the SMR entities. SDL-1/2/3 show the SMR entity on MS-side, and SDL-4/5 on the network side. 

The lower layers (below CM) are transparent to an SMR entity. 
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Annex E (informative): 
Cause definition 

E-l: CP-cause definition 

Cause no. 17: "Network failure" 

This cause is sent to the MS if the MSC cannot service an MS generated request because of PLMN failures, e.g. 
problems in MAP. 

Cause no. 22: "Congestion" 

This cause is sent if the service request cannot be actioned because of congestion (e.g. no channel, facility 
busy/congested etc.). 

Cause no. 81: "Invalid Transaction Identifier" 

This cause indicates that the equipment sending this cause has received a message with a Transaction Identifier 
which is currently not use on the MS - network interface. 

Cause no. 95: "Semantically incorrect message" 

This cause is used to report the receipt of a message with semantically incorrect content. 

Cause no. 96: "Invalid mandatory information" 

This cause indicates that the equipment sending this cause has received a message with non-semantical 
mandatory information element errors. 

Cause no. 97: "Message type non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message with a message type it does 
not recognize either because this is a message not defined or defined but not implemented by the equipment 
sending this cause. 

Cause no. 98: "Message not compatible with short message protocol state" 

This cause indicates that the equipment sending this cause has received a message not compatible with the Short 
Message protocol state. 

Cause no. 99: "Information element non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message which includes information 
elements not recognized because the information element identifier is not defined or it is defined but not 
implemented by the equipment sending the cause. 

However, the information element is not required to be present in the message in order for the equipment 
sending the cause to process the message. 

Cause no. Ill: "Protocol error, unspecified" 

This cause is used to report a protocol error event only when no other cause applies. 

E-2: RP-cause definition mobile originating SM-transfer 

Cause no. 1: "Unassigned (unallocated) number" 

This cause indicates that the destination requested by the Mobile Station cannot be reached because, although the 
number is in a valid format, it is not currently assigned (allocated). 

Cause no. 8: "Operator determined barring" 

This cause indicates that the MS has tried to send a mobile originating short message when the MS's network 
operator or service provider has forbidden such transactions. 
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Cause no. 10: "Call barred" 

This cause indicates that the outgoing call barred service applies to the short message service for the called 
destination. 

Cause no. 21: "Short message transfer rejected" 

This cause indicates that the equipment sending this cause does not wish to accept this short message, although it 
could have accepted the short message since the equipment sending this cause is neither busy nor incompatible. 

Cause no. 27: "Destination out of service" 

This cause indicates that the destination indicated by the Mobile Station cannot be reached because the interface 
to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling 
message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the 
remote user, user equipment off-line, etc. 

Cause no. 28: "Unidentified subscriber" 

This cause indicates that the subscriber is not registered in the PLMN (i.e. IMSl not known). 
Cause no. 29: "Facility rejected" 

This cause indicates that the facility requested by the Mobile Station is not supported by the PLMN. 

Cause no. 30: "Unknown subscriber" 

This cause indicates that the subscriber is not registered in the HLR (i.e. IMSl or directory number is not 
allocated to a subscriber). 

Cause no. 38: "Network out of order" 

This cause indicates that the network is not functioning correctly and that the condition is likely to last a 
relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be 
successful. 

Cause no. 41: "Temporary failure" 

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long 
period of time; e.g., the Mobile Station may wish to try another short message transfer attempt almost 
immediately. 

Cause no. 42: "Congestion" 

This cause indicates that the short message service cannot be serviced because of high traffic. 
Cause no. 47: "Resources unavailable, unspecified" 

This cause is used to report a resource unavailable event only when no other cause applies. 

Cause no. 50: "Requested facility not subscribed" 

This cause indicates that the requested short message service could not be provided by the network because the 
user has not completed the necessary administrative arrangements with its supporting networks. 

Cause no. 69: "Requested facility not implemented" 

This cause indicates that the network is unable to provide the requested short message service. 

Cause no. 81: "Invalid short message transfer reference value" 

This cause indicates that the equipment sending this cause has received a message with a short message 
reference which is not currently in use on the MS-network interface. 

Cause no. 95: "Invalid message, unspecified" 
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This cause is used to report an invalid message event only when no other cause in the invalid message class 
applies. 

Cause no. 96: "Invalid mandatory information" 

This cause indicates that the equipment sending this cause has received a message where a mandatory 
information element is missing and/or has a content error (the two cases are indistinguishable). 

Cause no. 97: "Message type non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message with a message type it does 
not recognize either because this is a message not defined or defined but not implemented by the equipment 
sending this cause. 

Cause no. 98: "Message not compatible with short message protocol state" 

This cause indicates that the equipment sending this cause has received a message such that the procedures do 
not indicate that this is a permissible message to receive while in the short message transfer state. 

Cause no. 99: "Information element non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message which includes information 
elements not recognized because the information element identifier is not defined or it is defined but not 
implemented by the equipment sending the cause. 

However, the information element is not required to be present in the message in order for the equipment 
sending the cause to process the message. 

Cause no. Ill: "Protocol error, unspecified" 

This cause is used to report a protocol error event only when no other cause applies. 

Cause no. 127: "Interworking, unspecified" 

This cause indicates that there has been interworking with a network which does not provide causes for actions it 
takes; thus, the precise cause for a message which is being send cannot be ascertained. 

E-3: RP-cause definition mobile terminating SM-transfer 

Cause no. 22: "Memory capacity exceeded" 

This cause indicates that the mobile station cannot store the incoming short message due to lack of storage 
capacity. 

Cause no. 81: "Invalid short message reference value" 

This cause indicates that the equipment sending this cause has received a message with a short message 
reference which is not currently in use on the MS-network interface. 

Cause no. 95: "Invalid message, unspecified" 

This cause is used to report an invalid message event only when no other cause in the invalid message class 
applies. 

Cause no. 96: "Invalid mandatory information" 

This cause indicates that the equipment sending this cause has received a message where a mandatory 
information element is missing and/or has a content error (the two cases are indistinguishable). 

Cause no. 97: "Message type non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message with a message type it does 
not recognize either because this is a message not defined or defined but not implemented by the equipment 
sending this cause. 

Cause no. 98: "Message not compatible with short message protocol state" 
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This cause indicates that the equipment sending this cause has received a message such that the procedures do 
not indicate that this is a permissible message to receive while in the short message transfer state. 

Cause no. 99: "Information element non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message which includes information 
elements not recognized because the information element identifier is not defined or it is defined but not 
implemented by the equipment sending the cause. 

However, the information element is not required to be present in the message in order for the equipment 
sending the cause to process the message. 

Cause no. Ill: "Protocol error, unspecified" 

This cause is used to report a protocol error event only when no other cause applies. 

E-4: RP-Cause definition memory available notification 

Cause no. 30: "Unknown Subscriber" 

This cause indicates that the subscriber is not registered in the HLR (i.e. IMSI or directory number is not 
allocated to a subscriber). 

Cause no. 38: "Network out of order" 

This cause indicates that the network is not functioning correctly and that the condition is likely to last a 
relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be 
successful. 

Cause no. 41: "Temporary failure" 

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long 
period of time; e.g., the Mobile Station may wish to try another short message transfer attempt almost 
immediately. 

Cause no. 42: "Congestion" 

This cause indicates that the short message service cannot be serviced because of high traffic. 
Cause no. 47: "Resources unavailable, unspecified" 

This cause is used to report a resource unavailable event only when no other cause applies. 
Cause no. 69: "Requested facility not implemented" 

This cause indicates that the network is unable to provide the requested memory available notification service. 

Cause no. 95: "Invalid message, unspecified" 

This cause is used to report an invalid message event only when no other cause in the invalid message class 
applies. 

Cause no. 96: "Invalid mandatory information" 

This cause indicates that the equipment sending this cause has received a message where a mandatory 
information element is missing and/or has a content error (the two cases are indistinguishable). 

Cause no. 97: "Message type non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message with a message type it does 
not recognize either because this is a message not defined or defined but not implemented by the equipment 
sending this cause. 

Cause no. 98: "Message not compatible with short message protocol state" 

This cause indicates that the equipment sending this cause has received a message such that the procedures do 
not indicate that this is a permissible message to receive while in the short message transfer state. 
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Cause no. 99: "Information element non-existent or not implemented" 

This cause indicates that the equipment sending this cause has received a message which includes information 
elements not recognized because the information element identifier is not defined or it is defined but not 
implemented by the equipment sending the cause. 

However, the information element is not required to be present in the message in order for the equipment 
sending the cause to process the message. 

Cause no. Ill: "Protocol error, unspecified" 

This cause is used to report a protocol error event only when no other cause applies. 

Cause no. 127: "Interworking, unspecified" 

This cause indicates that there has been interworking with a network which does not provide causes for actions it 
takes; thus, the precise cause for a message which is being send cannot be ascertained. 
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Annex F (informative): 

LAPDm SAPI 3 handling for short message service 

This annex describes several typical SMS message transfer scenarios for circuit switched GSM. 

For GPRS SMS transfer, refer to GSM 03.60 for channel set up and upper layer message flow. 

Case A: Mobile originating short message transfer, no parallel call. 

The mobile station side will initiate SAPI 3 establishment by a SABM command on the SDCCH after the cipher 
mode has been set. If no hand over occurs, the SAPI 3 link will stay up until the last CP-ACK is received by the 
MSC, and the clearing procedure is invoked. 

Case B: Mobile terminating short message transfer, no parallel call. 

The network side, i.e. the ESS will initiate SAPI3 establishment by a SABM command on the SDCCH when the 
first CP-Data message is received from the MSC. If no hand over occurs, the link will stay up until the MSC has 
given the last CP-ack and invokes the clearing procedure. 

Case C: Mobile originating short message transfer, parallel call. 

The mobile station will send a SABM command on the SACCH when a CM_SERV_ACC message has been 
received from the network, allowing the short message transfer to start. If no hand over occurs the link will stay 
up until the MSC orders a explicit release, or the clearing procedure is invoked. If the parallel call is cleared 
before the short message transfer is finalized, the MSC will delay the clearing procedure toward the BSS, i.e. the 
channel release procedure is delayed. 

Case D: Mobile terminating short message transfer, parallel call. 

The network side, i.e. the BSS will initiate SAPI3 establishment by a SABM command on the SACCH when the 
first CP-DATA message is received from the MSC. The further handling is exactly as described for case C. 

Case E: Mobile terminating short message transfer together with Inter-MSC hand over, parallel call. 

The MAP procedures "Forward access signalling" and "Process access signalling" will be used between the two 
MSCs to transfer the CP-DATA, CP-ACK and CP-ERROR messages. 

Case F: Mobile terminating short message transfer on SDCCH channel together with Inter-MSC hand over. 

The MAP procedures "Forward access signalling" and "Process access signalling" will be used between the two 
MSCs to transfer the CP-DATA, CP-ACK and CP-ERROR messages. 
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Figure F1/GSM 04.11 : Mobile originated Shiort lUlessage on SDCCH 
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Figure F2/GSM 04.11 : Mobile terminated Shiort lUlessage on SDCCH 
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Figure F6/GSIUI 04.1 1 : Inter/IUISC handover during Short IVIessage transfer on SDCCH 
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